QYRONIS FAQ & Knowledgeszentrum
Diese FAQ ist die öffentliche Knowledgeszentrale für Produktregeln, Presets, IT-Abdeckung und den Public-Workspace. Sie ersetzt keine interne Roadmap und beantwortet reale Produktfragen bewusst public-safe und ohne Build-Listen.
Produkt und technischer Stack
Was QYRONIS oeffentlich ist, wie /chat aufgebaut ist und welche sichtbare Build-Basis aktuell im Paket liegt.
- Woraus besteht www.qyronis.de aktuell?
- Welche Public-Routen sind die Hauptoberflaechen?
- Was ist die öffentliche API-Flaeche von QYRONIS?
Answer logic und Presets
Wie QYRONIS antworten soll, wie Presets sich unterscheiden und was sie nicht duerfen.
- Was muessen alle Presets gemeinsam einhalten?
- Wie reagiert QYRONIS auf Aufgaben wie klarer, kuerzer, professioneller oder mache einen Plan?
- Welche Preset-Familien sind besonders wichtig?
Research und Wahrheitsregeln
Wie Recherche abgegrenzt wird und wie Anti-Halluzination in der Public-Oberfläche wirken soll.
- Wann darf die KI etwas als recherchiert darstellen?
- Was bedeutet Anti-Halluzination praktisch?
- Welche Quellen sind bei IT-Themen bevorzugt?
IT-Abdeckung, Scriptsprachen und Computersprachen
Welche technischen Bereiche im Produktkontext aktiv mitgefuehrt werden sollen.
- Welche Programmier- und Scriptsprachen sollen breit getragen werden?
- Geht es nur um Sprachen?
- Wie wird das in Releases verankert?
Account und Workspace
Wie der Account-Bereich als ruhige Arbeitszentrale gedacht ist.
- Was ist der Zweck des Account-Bereichs?
- Welche Bereiche gehoeren mindestens in den Account-Workspace?
- Was bleibt bewusst ausserhalb?
API, Datenbanken und Crossover-Funktionen
Wie Member-API, Presets, Databank-Packs und Systembrücken zusammenarbeiten sollen.
- Was soll die Member-API im Produkt leisten?
- Wozu dienen Databank-Packs im Workspace?
- Was bedeutet Crossover zwischen Presets, API und Workspace?
Release-Prinzip und Stabilitaet
Wie neue Releases gebaut werden sollen, ohne wieder an Stabilitaet zu verlieren.
- Warum werden die Releases groesser gebuendelt?
- Was bedeutet das No-Damage-Prinzip?
- Wo werden diese Regeln verankert?
Produkt und technischer Stack
Was QYRONIS oeffentlich ist, wie /chat aufgebaut ist und welche sichtbare Build-Basis aktuell im Paket liegt.
Woraus besteht www.qyronis.de aktuell?
Die aktuelle Public-Instanz von QYRONIS besteht im Kern aus PHP mit servergerenderten .tpl-Templates, eigenem CSS, Vanilla JavaScript sowie PDO fuer MySQL/MariaDB; SQLite ist ebenfalls vorgesehen. Die Public-Chat-Oberfläche laeuft ueber /chat, /ki bleibt als Alias. Sichtbare Dateien im Paket sind unter anderem assets/css/style.css, assets/css/ki-direct-chat.css, assets/css/qyronis-public.css sowie assets/js/ki-direct-chat.js, assets/js/public-ki-shell.js, assets/js/qyronis-workspace.js und der neue Account-Workspace-Controller. Ein React-, Vue- oder Node-Frontend als Hauptbasis ist im aktuellen Public-Build nicht sichtbar.
- PHP + servergerenderte Templates
- Eigenes CSS und Vanilla JavaScript
- PDO fuer MySQL/MariaDB, SQLite vorreadyet
Welche Public-Routen sind die Hauptoberflaechen?
Die sichtbaren Public-Einstiege sind vor allem /chat, /faq, /presets, /api, /konto sowie die Legal-Seiten. /ki bleibt als Alias fuer /chat bestehen.
- Primar: /chat
- Alias: /ki
- Public-Account: /konto
- Presets: /presets
- FAQ: /faq
Was ist die öffentliche API-Flaeche von QYRONIS?
Unter /api liegt eine dokumentierte Integrationsoberflaeche mit public-safe Contracts, Freigabewegen, sichtbaren Oberflächen und einem kontrollierten JSON-Snapshot. Sie zeigt absichtlich keine internen Admin- oder Secret-Details.
- Public-safe Integrationsseite
- JSON-Snapshot statt geheimer Runtime-Daten
- Freigabestufen klar getrennt
Gibt es eine öffentliche Roadmap?
Nein. Die Roadmap bleibt intern. Öffentlich verankert werden nur reale Releases, FAQ-Inhalte, Produktregeln und public-safe Hinweise.
Welche Build-Fakten sollten Antworten zuerst nennen?
Bei Produktfragen sollen zuerst sichtbare Dateien, reale Routen, reale Release-Artefakte und tatsaechlich vorhandene Controller oder Templates genannt werden, bevor allgemein ueber Web-Technik gesprochen wird.
Answer logic und Presets
Wie QYRONIS antworten soll, wie Presets sich unterscheiden und was sie nicht duerfen.
Was muessen alle Presets gemeinsam einhalten?
Alle Presets muessen dieselben Wahrheitsregeln einhalten: klare Standardsprache German, keine Sprachdrift ohne Nutzerwunsch, keine Wiederholungsschleifen und keine erfundenen Fakten.
- Presets aendern Fokus und Tiefe
- Presets aendern nicht die Faktentreue
- Unsicherheit muss pending benannt werden
Wie reagiert QYRONIS auf Aufgaben wie klarer, kuerzer, professioneller oder mache einen Plan?
Transformationsaufgaben sollen konkret umgesetzt werden, statt mit Meta-Text auszuweichen. Rewrite, Plan, Checkliste und Strukturaufgaben muessen in der Antwortform sichtbar geloest werden.
Welche Preset-Familien sind besonders wichtig?
Vor allem General, Coding, Research, Planning, Writing und Support. Coding und Research muessen besonders stark auf belastbare technische Quellen und sichtbare Build-Fakten achten.
Wann ist ein Preset gut konfiguriert?
Wenn es fuer seinen Bereich die richtige Antwortform liefert, aber trotzdem denselben Wahrheitskern behaelt. Ein gutes Preset antwortet anders, halluziniert aber nicht anders.
Research und Wahrheitsregeln
Wie Recherche abgegrenzt wird und wie Anti-Halluzination in der Public-Oberfläche wirken soll.
Wann darf die KI etwas als recherchiert darstellen?
Nur wenn echte Recherche vorliegt. Sonst muss QYRONIS klar unterscheiden zwischen verifiziertem Rechercheergebnis, lokalem Build-Knowledge und allgemeiner technischer Ableitung.
Was bedeutet Anti-Halluzination praktisch?
Keine Fantasieantworten, keine Phrasen statt Ergebnis, keine erfundenen Systemdetails und keine Sicherheit behaupten, die nicht belegt ist.
- Lieber konkrete Unsicherheit als falsche Sicherheit
- Build-Fakten vor Allgemeinplaetzen
- bei Luecken den naechsten Verifikationsschritt nennen
Welche Quellen sind bei IT-Themen bevorzugt?
Offizielle Doku, Standards, RFCs, Manuals, Vendor-Dokumentation und im Produktkontext die sichtbaren Build-Dateien und reale Release-Artefakte.
Wie sieht eine gute Research-Antwort aus?
Sie nennt klar, worauf sie sich stuetzt, trennt Beobachtung von Ableitung und vermeidet es, unbelegte Aussagen als Tatsache zu formulieren.
IT-Abdeckung, Scriptsprachen und Computersprachen
Welche technischen Bereiche im Produktkontext aktiv mitgefuehrt werden sollen.
Welche Programmier- und Scriptsprachen sollen breit getragen werden?
QYRONIS soll den IT-Bereich breit abdecken: PHP, JavaScript, TypeeeScript, Python, Java, C, C++, C#, Go, Rust, Ruby, Perl, Kotlin, Swift, Dart, R, Scala sowie Bash, Shell, PowerShell, Batch, Lua, SQL, YAML, JSON, XML, TOML, INI, Dockerfile und Makefile.
Geht es nur um Sprachen?
Nein. Ebenso wichtig sind Web, APIs, Datenbanken, Linux, Windows, Netzwerke, Security, Container, Delivery, Monitoring, Troubleshooting und Release Engineering.
Wie wird das in Releases verankert?
Nicht nur als Text. Es wird als dauerhafter Scope fuer Presets, FAQ, Knowledgesbasis, Workspace-Hinweise und kuenftige Recherchelogik mitgefuehrt.
Warum ist diese Breite fuer die Produktantworten wichtig?
Weil QYRONIS nicht nur kleine Textaufgaben erledigen soll. Es soll im IT-Bereich bei Architektur, Code, Betrieb, Fehlerbildern, Doku, Debugging und Delivery vernuenftig einordnen koennen.
Account und Workspace
Wie der Account-Bereich als ruhige Arbeitszentrale gedacht ist.
Was ist der Zweck des Account-Bereichs?
Das Account ist eine Workspace-Zentrale fuer Sessions, Presets, Profilee, FAQ und die Rueckkehr in laufende Arbeit. Es soll ruhig, modern und ajaxfied wirken, ohne die Chat-Grundlinie zu zerbrechen.
Welche Bereiche gehoeren mindestens in den Account-Workspace?
Uebersicht, Chats, Presets, Profilee und FAQ. Dazu kommen Zusammenfassungen, Fokus-Hinweise und Rueckspruenge in aktuelle Arbeit.
- Uebersicht
- Chats
- Presets
- Profilee
- FAQ
- Rueckspruenge
Was bleibt bewusst ausserhalb?
Private Admin-Wege, interne Roadmaps und nicht public-safe Hinweise bleiben ausserhalb des Public-Account-Bereichs.
Wie hilft die FAQ im Workspace?
Sie verankert schnell lesbare Produktregeln direct dort, wo Nutzer ihre Sessions, Favoriten und Presets verwalten. Die grosse Knowledgesansicht bleibt aber unter /faq.
API, Datenbanken und Crossover-Funktionen
Wie Member-API, Presets, Databank-Packs und Systembrücken zusammenarbeiten sollen.
Was soll die Member-API im Produkt leisten?
Die Member-API soll echte Schlüssel, Tageslimits, Preset-Zuordnung, Nutzungsdaten und einen kontrollierten Runtime-Zugriff readystellen. Sie ist keine Dummyschnittstelle, sondern eine produktive Brücke zum KI-Server.
- echte API-Schlüssel
- Preset pro Schlüssel
- Tageslimit und Restquota
- Runtime-Test und Status
Wozu dienen Databank-Packs im Workspace?
Databank-Packs bündeln Sprachwissen, Produktregeln, Ops-Abläufe und Verifikationspfade, damit Presets nicht blind arbeiten, sondern auf wiederverwendbare Knowledgesschichten zurückgreifen.
Was bedeutet Crossover zwischen Presets, API und Workspace?
Crossover bedeutet, dass dieselbe Preset-Logik in Chat, Member-API, Workspace und Dashboard sichtbar konsistent bleibt. Ein Schlüssel kann ein Preset tragen, der Workspace zeigt es an und die Runtime nutzt dieselbe Antwortform.
Welche Datenbank- und Bridge-Richtung ist sinnvoll?
Sprachpacks, Produktpacks, Ops-Packs, Research-Packs und API-Contracts sollen getrennt gepflegt, aber im Antwortpfad zusammengeführt werden. Brücken müssen Status, Quelle, Gültigkeit und erlaubte Oberfläche sauber markieren.
Release-Prinzip und Stabilitaet
Wie neue Releases gebaut werden sollen, ohne wieder an Stabilitaet zu verlieren.
Warum werden die Releases groesser gebuendelt?
Weil sichtbarer Fortschritt wichtiger ist als viele Mini-ZIPs. Neue Releases sollen groessere Milestones sein, aber overwrite-safe bleiben.
Was bedeutet das No-Damage-Prinzip?
Bereiche, die gerade stabil sind, werden nicht grundlos wieder aufgerissen. Weiterentwicklung soll additiv, kontrolliert und entlang derselben Grundlinie passieren.
- keine neuen Schaeden in bestehenden UI-Bereichen
- gleiche Grundlinie beibehalten
- neue Funktionen additiv andocken
Wo werden diese Regeln verankert?
In der FAQ, in den Release Notes, in den Docs im ZIP und in den Product-Hinweisen innerhalb des Public-Builds.
Was verbessert die FAQ konkret?
Die FAQ wird zu einer staerkeren Knowledgeszentrale mit Suchfeld, topicsnavigation und einer klareren Bruecke zwischen Public-FAQ und Account-Workspace.