initial-prompt.md

c130 - Native App

Contents

More than one cycle
Directives and plans
Native App
GPUI kit (and other aspects of this new framework we'll be building in)
New Web App

More than one cycle

This initial prompt will likely result in several cycles to keep our context clean for each agent.

(These are high level and don't reach the requirements of our plan yet. These are good to know about the direction of the complan. The ../market-analyst agent has recently analyzed the meeting where these were discussed. Skim the relevant records to know the specifics).

Roadmap

We are removing qdash from ../qcontrol. It will be an optionally installable web app for intrspecting and governing a company wide ai ecosystem.

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.

GPUI kit (and other aspects of this new framework we'll be building in)

Research and understand the things we need to know about this new ecosystem. Let's summarize for both the designers and the builders so we know the new system we're working in. We may work with the Figma mcp, our illustrator rendering skills to create design prototypes for the designers wo manually work on. We'll cross that bridge later, but research resources that are already out ther
- MCP servers
- Skills
- Tools
- Docs
- Demos
- videos for overview (ususally human understanding)
- etc.
Prepare educational overview and suggestion around the shape that the app should take. The following items should be considered true:
- We're using the native visual expression whenever possible
- The app will ber connected to and conversant with our web app. They should play well together un unforseen ways as well as a few possibilities:
  - Messaging?
    - Notices from HQ
    - Confimations
      - Identity
      - Censures
        Stop doing X, Y, Z
      - You are now responsible for..
    - Training
  - Integrations
    - Links to places on the web app
      - You're making these violations, take the following brief training. Training noted and entered into the audit log for proof of correction.
    - New idea (see previous item) that deserves it's own cycle. Remediation Training. They can be short and too the point. But we're uniquely situated to provide these trainings. Lean into hard-hat training and Metamythic (previous experience, Mark Parson). As we learn things that should or should not be done, we're creating micro trainings with tese potential attributes
      - illustrations
      - animations
      - quizes (verifications of concept understanding)
      - videos?
      - content
      - etc
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?
Design prototyping. Let's evaluate and define a process for mocking up aspects of the GPUI kit UI and workflow as we currently do (see phase work under pages). I'd like to continue our patter of prototype, experiment and refine in design, then push into the real app. What should that look like? What tools at our disposal? agent tools?

New Web App

The new web app is already perfectly modeled with ../app.qpoint.io. We are replicating it directly–including the back-end / database (caveat, we're currently using firebase, but that's not an option because we need self hosting, this will be replaced with something).
The app will be self-hosted by the company.

greater data trust
we are less liable for the uptime thus reducing our technical responsibility surface area
we lose some ability to see problems, but can offset in other ways.

We will be using q-nuxt-layer