c131. Native App V1

Stage 1, split from c130's initial prompt on 2026-11-09. The passages below are Mark's words from ../c130.native-app/initial-prompt.md, unchanged. The roadmap session is market-analyst 1b21a3ce (2026-11-05). The program plan that sorts the work is ../c130.native-app/plan.md.

From c130's initial prompt

Qdash receives a new-to-be-designed-and-built native app including the responsibility for the tray app.

Designing and building this native app becomes priority number 1 to be rollowed rapidly with the optionally deployable web app.

Native App

We will now be building a native app (native to mac, windows & linux) using GPUi -

• GPUI kit : https://gpui-kit.com/
• Native Shell : https://nsh.dev/

We want to

• first, benefit from the native windows, buttons, etc. We're not here to re-invent the wheel. If there is a good existing piece of UI, let's use that first
• Second, are you sure, there isn't an existing piece of UI? We may need to modify how we're showing the data. Let's do so if we don't materially change the thing we're showing. (joke, but true–we want to mostly use what's already created)
• implement our brand in this GPUI kit to get the benefit of much simpler native deployment.
• Design the app in our Qpoint flavored GPUI
  • This flavor is more subtle-to-non-existent at first
• There are two potential outcomes, we're start the moves that will help us accomplish either.
  • A. pivot our current UI work into the new native app that will be forthcomeing from the engineers, prepare to attach to the app at the UI layer outlined and demonstrated elsewhere.
  • B. create V1 ourselves–a simple port of our current work–and hand it to the engineers who will be working on it
    • Show the patterns by implementing them
    • Have all the pages functioning under synthetic data and ready to have real data swapped out
      • Should we componentize this?
        • DataNozel with simple switch
          • `data: <synthetic, real>
          • we don't want to muck up the app with synthetic data, so I would hope that this is more of a switch. When active, look for the synthetic data source, when set to real data, look for the provided API urls. ie: synthetic true, look for th esynthetic data store always provided in x standard location
• I lean towards creating the app. Perhaps the eingineers use it as a prototype and they build their own. Regardless, let's start with our own and present it as an option on kick off. This is one of the primary purposes of this brief–though we will want to split it off into it's own cycles, prbly c131.
  • We are re-purposing the ../app.qpoint.io backend and vue patterns.
  • we'll neatly slip our ../qcontrol app / prototype in to the current ..app.qpoint.io slot.
• Let's build the V1 of the app as a starting point.
  • We'll be replicating many aspects of the current ../qcontrol dash-ui app.
    • Inventory
    • Live view
    • At some point, we're going to be using qmap, maybe we could include a link to view a qmap back in the dashboard since we're probably not going to embed it here unless we can think of a way to not impact important performace metrics that are critical in some implementations (CPU, RAM, etc)
      • optionally include it as opted in?
      • include it as an optional secondary web app (nuxt, etc) that runs locally?

Pointers

• Program plan and gates: ../c130.native-app/plan.md (this cycle opens at G1, the shape ruled).
• Tyler's sketch of the app and the control plane: ../../../market-analyst/sessions/2026-11-05-1b21a3ce.md.
• What exists to port: ../../../qcontrol/crates/qdash/ui (the pages and the data-interface bible), ../../../qcontrol/crates/qtray (the tray today, macOS only).

Create a plan, ask any clarifying questions, suggest patterns I may not be considering.