VectorUP

ectorUP startet som et ganske enkelt prosjekt fordi jeg ønsket en bedre måte å organisere det jeg faktisk bruker på en PC. Etter hvert som antallet programmer, mapper, nettsider, kommandoer og utviklingsverktøy øker, blir også den tradisjonelle måten å finne ting på mindre effektiv. Startmenyen blir full, snarveier havner overalt, mapper ligger forskjellige steder og en del av det man bruker mest er ikke engang et program, men kanskje en URL, en terminalkommando eller en bestemt prosjektmappe. VectorUP ble derfor først tenkt som en launcher som kunne samle dette på en ryddigere måte, men det ble ganske raskt tydelig at det samme behovet går igjen i mange flere deler av arbeidsflyten.

Navnet kommer fra det som fortsatt er hovedideen i prosjektet. Vector handler om retning, altså at brukeren vet hva han eller hun ønsker å gjøre, men ikke nødvendigvis vil bruke tid på å huske hvor verktøyet ligger eller hvordan det startes. UP står for Unified Portal, fordi målet er å samle forskjellige typer ressurser bak en felles måte å finne og bruke dem på. Fullt navn blir dermed Vector Unified Portal. Det betyr ikke at alle funksjoner skal presses inn i samme skjerm, men at de skal henge sammen og bruke samme språk, samme søk, samme organisering og samme logikk der det er naturlig.

Selve kjernen i VectorUP er fortsatt en launcher og et bibliotek. Applikasjoner, nettsider, mapper, kommandoer og workspaces kan registreres som egne elementer, og brukeren kan organisere dem med kategorier, favoritter, beskrivelser, søkeord og andre metadata. Målet er at brukeren i minst mulig grad skal måtte bry seg om hvilken teknisk type noe er. Hvis man vet at man ønsker å åpne Audacity, en prosjektmappe eller en bestemt nettside, skal det kunne finnes og åpnes på omtrent samme måte. Samtidig beholdes forskjellene der de faktisk betyr noe, slik at en Command fortsatt kan ha execution target og variabler, mens en Web Tool kan bygge en URL basert på brukerinput.

Søket er derfor en sentral del av løsningen. Vanlig bruk skal være enkelt, slik at det holder å skrive deler av et navn, et alias eller et søkeord, men søket er også bygget for å kunne bli mer avansert uten at det krever en egen komplisert søkeside. Det kan etter hvert brukes strukturerte filtre som type, kategori og andre felt, i tillegg til eksakte fraser, wildcards og sammenligninger der metadataene støtter det. Tanken er at samme søkefelt skal kunne fungere både for en bruker som bare skriver «audacity» og for en mer avansert bruker som ønsker å finne alle Commands i en bestemt kategori eller filtrere på andre egenskaper.

Quick Launcher er den raske inngangen til dette. Den er laget for å kunne åpnes uten å bytte arbeidskontekst og vise treff fra både apper, lokale elementer og andre VectorUP-objekter. Resultatene kan åpnes direkte, men de kan også ha egne handlinger, for eksempel Inspect, Copy eller andre typeavhengige funksjoner. Quick Launcher er derfor ikke bare et søkefelt, men en rask kommandoflate for det som finnes i VectorUP.

Library er den mer organiserte delen av systemet. Her skal det være mulig å bla gjennom hele samlingen, filtrere på type og kategori og velge hvordan innholdet vises. Det utvikles flere visningsmoduser fordi forskjellige situasjoner krever forskjellig mengde informasjon. Compact er beregnet på rask visuell browsing med mange elementer samtidig, Cards viser ikon, navn og beskrivelse og er bedre når man ikke kjenner programmet fra før, mens List bruker bredden mer effektivt til beskrivelse, type og annen metadata. Dette er viktig spesielt for applikasjoner som har navn som ikke nødvendigvis sier noe om hva de faktisk gjør.

Nettsider kan registreres som vanlige Websites, men de kan også utvides til Web Tools. En vanlig Website åpner en fast adresse, mens en Web Tool kan bruke en parameterisert URL. Et eksempel kan være en side for å slå opp EU-kontroll, hvor VectorUP spør etter registreringsnummer og setter verdien inn i URL-en før siden åpnes. Web Tools bruker samme generelle variabelmodell som andre deler av systemet, slik at verdier kan komme fra brukeren, clipboard, valgt tekst eller lokale/systemrelaterte verdier som hostname, brukernavn, lokal IP, ekstern IP, dato og klokkeslett. Hensikten er at brukeren ikke skal måtte lære ett variabelsystem for nettsider og et annet for kommandoer.

Commands følger samme tankegang. Det enkleste tilfellet kan være en helt vanlig kommando som kpmforge, som lagres med navn og eventuelt ikon og kategori og deretter oppfører seg som et vanlig launcher-element. Mer avanserte Commands kan inneholde variabler som ping {host} eller bruke dynamiske verdier som {local_ip}. De kan kjøres gjennom Windows Shell, PowerShell, WSL eller automatisk target-valg, og de kan også inngå i workflows. Poenget er at en enkel Command skal være enkel å lage, mens de mer avanserte funksjonene finnes tilgjengelig når man faktisk trenger dem.

Notebook ble lagt til fordi behovet for å lagre tekst, kode, kommandoer og små biter med informasjon viste seg å være tett knyttet til resten av arbeidsflyten. I stedet for å bruke et tilfeldig Notepad++-vindu til alt fra midlertidig tekst til permanente kommandoer, har VectorUP nå en egen notatflate. Et notat kan være Plain, Code, Markdown eller Rich. Code bruker syntax highlighting uten å endre selve kildeinnholdet, Markdown kan vises som ren kilde, preview eller split view, og Rich bruker en strukturert editor med overskrifter, lister, checklister, kodeblokker, tabeller og inline-bilder. Notater autosaves, har historikk som standard, kan pinnes, kategoriseres, tagges, arkiveres og søkes, og brukeren kan selv velge om innholdet skal være med i søkeindeksen.

Notebook støtter også attachments. Filer kan kopieres inn i VectorUPs eget storage-område eller lenkes til original plassering. Bilder kan limes inn og vises inline, mens andre filer kan åpnes, vises i vedleggslisten eller brukes videre i andre deler av systemet. Dette førte samtidig til at VectorUP fikk et mer generelt storage_objects-fundament, slik at samme fysiske fil senere kan brukes fra Notebook, Workbench eller en fremtidig File Library uten at hver funksjon må lage sin egen kopi og sin egen lagringslogikk.

Workbench er laget for arbeid hvor man trenger å samle kontekst, bygge prompts, sammenligne svar og jobbe videre med resultatet. Det er ikke avhengig av direkte integrasjon mot en bestemt KI-leverandør. En Workbench Session kan inneholde filer, Notebook-notater, clipboard, manuell tekst, feilmeldinger og andre kontekstkilder. Hver kilde kan aktiveres eller deaktiveres, rekkefølgen kan endres og den kan få en rolle som eksempelvis Source code, Requirements eller Error/Log. Workbench viser estimert tokenbruk både totalt og per kilde, slik at det blir tydelig hva som faktisk tar plass i konteksten.

Prompt-delen kan brukes som rå tekst eller mer strukturert med felter som Goal, Requirements, Constraints, Examples og Expected output. Uansett form vises en ferdig assembled preview før teksten kopieres, slik at brukeren kan se nøyaktig hva som skal sendes videre. Workbench bruker også det samme variabelsystemet som resten av VectorUP. Etter at svar er mottatt fra ulike KI-modeller eller andre kilder, kan de lagres i samme session, vises som Markdown, analyseres for kodeblokker og sammenlignes side om side eller som diff. Et sluttresultat kan merges manuelt og sendes videre til Notebook.

Inspector er et felles system for å se hva et objekt faktisk er og hvor det kommer fra. Det brukes blant annet i Workbench, Library, Notebook og Quick Launcher. En applikasjon kan inspiseres for å se target, aliases, kategori, brukshistorikk og icon source. Et notat kan vise mode, tags, revisions og attachments. En Command kan vise template, execution target og variabler. En Workbench-kilde kan vise tokenbidrag, linjeområde og om den er live eller snapshot. Inspector er laget som en read-only capability som henter data fra de eksisterende domenemodellene, ikke som enda et sted som eier og redigerer samme data.

Et annet stort område er Repositories, hvor målet er å gjøre lokal Git-bruk langt mer oversiktlig. VectorUP skal kunne registrere en lokal katalog, oppdage om den allerede er et Git-repository eller initialisere Git eksplisitt hvis brukeren ønsker det. Deretter kan systemet vise branch, HEAD, upstream, ahead/behind, staged, unstaged, untracked files, conflicts, history, branches, remotes, stash og worktrees. Selve Git-operasjonene skal bruke brukerens installerte Git CLI som sannhetskilde, slik at VectorUP følger samme config, credentials, SSH, hooks og Git-versjon som brukeren ellers gjør.

En viktig del av Git-arbeidet er skillet mellom Git-status, remote-status og backup-status. En commit er ikke nødvendigvis en backup, og en push betyr heller ikke at hele arbeidskatalogen er sikret. Derfor bygges det støtte for både Git Bundle Backup og Workspace Snapshots. Bundle brukes til committed Git-historikk og refs, mens Workspace Snapshot er ment å bevare staged, unstaged og relevante untracked changes. Når disse brukes sammen kan VectorUP etablere en verifisert backup-baseline og vise hvilke filer som faktisk har endret seg siden siste backup.

Det betyr at repository-visningen kan bli mer menneskelig enn en tradisjonell Git-status. I stedet for bare å vise M src/App.tsx kan VectorUP vise at filen er endret siden siste verifiserte backup, hvor mange linjer som er lagt til eller fjernet, og om repositoryet har commits som ikke er pushet. Manuell backup skal kunne kjøres når brukeren ønsker det, og samme baseline kan brukes til å sammenligne current state mot siste backup, tidligere backups eller HEAD. Mer risikable operasjoner kan få tilbud om Safety Snapshot først, slik at nåværende arbeidsstatus kan bevares før eksempelvis restore, merge eller andre operasjoner som kan få større konsekvenser.

Worktrees er også relevante i dette systemet fordi de gjør det mulig å jobbe på flere branches samtidig i forskjellige kataloger. Dette er nyttig i vanlig utvikling, men spesielt interessant når man bruker kodeagenter eller flere parallelle arbeidsløp. En agent kan arbeide i en separat worktree mens hovedkatalogen forblir på en annen branch. Workbench-integrasjonen gjør det i tillegg mulig å sende en diff, commit, konflikt eller endringer siden siste backup direkte inn som strukturert kontekst, med repository, branch, HEAD og filinformasjon bevart.

Home fungerer som den mer daglige inngangen til VectorUP. Her er hensikten å vise det man faktisk bruker mest, ikke å lage et stort dashboard. Kategorier fungerer som filter for innholdet, mens Favorites, Recently used, Most used og Folders gir rask tilgang til vanlige ressurser. Under dette finnes en full item-browser hvor man kan sortere, filtrere og bytte mellom Compact, Cards og List. Moduler som klokke, systemstatus og vær ligger i en separat utility rail slik at de ikke tar over hovedflaten.

VectorUP er bygget local-first. Det skal ikke være nødvendig med konto eller ekstern backend for å bruke kjernen i programmet, og data skal som hovedregel ligge lokalt. Eksterne tjenester kan brukes der de faktisk gir mening, for eksempel Git remotes, Web Tools eller fremtidige GitHub-integrasjoner, men det skal være tydelig når data forlater maskinen. Dette gjelder spesielt Workbench og variabelsystemet, hvor lokale eller kontekstuelle verdier skal være synlige før de brukes mot en ekstern URL eller annen tjeneste.

Prosjektet har også et Feature Selector-system med nivåene Basic, Enhanced, Advanced og Full. Hensikten er ikke å lage fire forskjellige utgaver av VectorUP, men å gi forskjellige typer brukere et fornuftig startnivå. En vanlig bruker trenger ikke å se Smart Commands, avanserte variabler eller tekniske Inspector-felt før det er relevant, mens en utvikler eller tekniker kan åpne hele verktøykassen. Innstillingene er fortsatt individuelle, slik at nivåene fungerer mer som presets enn faste begrensninger.

VectorUP er fortsatt under aktiv utvikling, og flere av områdene over er i forskjellige stadier. Noe er allerede implementert og i bruk, mens annet fortsatt bygges og justeres etter hvordan det fungerer i praksis. Det er også en viktig del av prosjektet at funksjoner ikke bare legges til fordi de høres interessante ut. De skal helst løse et konkret problem, bruke de samme grunnprinsippene som resten av programmet og kunne kobles til eksisterende systemer uten å bli et nytt isolert hjørne av applikasjonen.

Det som startet som en launcher har derfor utviklet seg til et lokalt arbeidsmiljø hvor applikasjoner, nettsider, mapper, kommandoer, notater, filer, Git-repositories og KI-relatert arbeid kan kobles sammen uten at de mister sin egen funksjon. Målet er ikke å erstatte alle andre programmer, men å redusere friksjonen mellom dem. VectorUP skal vite hva du bruker, hvordan ting henger sammen og hvordan du kommer deg raskest fra det du ønsker å gjøre til det verktøyet, innholdet eller prosjektet du faktisk trenger.