"""Streamlit Community Cloud entry point — public demo app.

This is the file Streamlit Community Cloud auto-discovers when you
deploy from this repository: leave the "Main file path" field at its
default (``streamlit_app.py``) and it just works.

Why this lives at the repo root, not in ``src/gui/``:
    Streamlit auto-detects sibling files inside a ``pages/`` directory
    next to the entry script and renders them as additional pages in
    the sidebar. The full product GUI's pages live in
    ``src/gui/pages/`` — pointing the Cloud at ``src/gui/app_demo.py``
    would inadvertently expose every paid-product page in the demo's
    sidebar (or require URL-routing tricks to suppress them).
    Anchoring the entry script at the repo root means there is no
    ``pages/`` neighbour and the demo stays single-page by
    construction.

The actual demo UI is defined once in ``src/gui/app_demo.py`` so
local development still works the way it always did:

    streamlit run src/gui/app_demo.py     # local dev, identical UX

Cloud deploy uses this shim:

    streamlit run streamlit_app.py        # what Cloud invokes
"""

from __future__ import annotations

import sys
from pathlib import Path

# Put the repo root on sys.path so ``src.core`` and ``src.gui`` imports
# resolve cleanly. The demo module does this itself for the local-dev
# case, but the import order matters when this shim runs first on Cloud.
_HERE = Path(__file__).resolve().parent
if str(_HERE) not in sys.path:
    sys.path.insert(0, str(_HERE))

# Executing the demo module top-to-bottom is the simplest way to share
# the UI between the two entry points without duplicating code or
# refactoring the demo into a function (Streamlit's idiom is
# script-as-page; converting it to a callable would fight the
# framework). ``runpy`` runs the file in this script's namespace so
# Streamlit's ``st.set_page_config`` / element registration sees the
# correct module.
import runpy
runpy.run_path(
    str(_HERE / "src" / "gui" / "app_demo.py"),
    run_name="__main__",
)