Public FAQ

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.

7Themenbloecke
29Verankerte Antworten
public-safekeine Build-Liste
4Databank layer
Schnellstart

Produkt und technischer Stack

Was QYRONIS oeffentlich ist, wie /chat aufgebaut ist und welche sichtbare Build-Basis aktuell im Paket liegt.

Schnellstart

Answer logic und Presets

Wie QYRONIS antworten soll, wie Presets sich unterscheiden und was sie nicht duerfen.

Schnellstart

Research und Wahrheitsregeln

Wie Recherche abgegrenzt wird und wie Anti-Halluzination in der Public-Oberfläche wirken soll.

Schnellstart

IT-Abdeckung, Scriptsprachen und Computersprachen

Welche technischen Bereiche im Produktkontext aktiv mitgefuehrt werden sollen.

Schnellstart

Account und Workspace

Wie der Account-Bereich als ruhige Arbeitszentrale gedacht ist.

Schnellstart

API, Datenbanken und Crossover-Funktionen

Wie Member-API, Presets, Databank-Packs und Systembrücken zusammenarbeiten sollen.

Schnellstart

Release-Prinzip und Stabilitaet

Wie neue Releases gebaut werden sollen, ohne wieder an Stabilitaet zu verlieren.

7 Themen gefunden
29 Antworten sichtbar
Alle topics Ohne Filter
FAQ Bereich

Produkt und technischer Stack

Was QYRONIS oeffentlich ist, wie /chat aufgebaut ist und welche sichtbare Build-Basis aktuell im Paket liegt.

Produkt, Routen und sichtbare Build-Fakten 5 Antworten
produkt stack php tpl javascript css routen build
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.

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.

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.

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.

FAQ Bereich

Answer logic und Presets

Wie QYRONIS antworten soll, wie Presets sich unterscheiden und was sie nicht duerfen.

Praezision, Fokus und saubere Antwortformen 4 Antworten
antwortlogik preset rewrite plan checkliste deutsch it support
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.

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.

FAQ Bereich

Research und Wahrheitsregeln

Wie Recherche abgegrenzt wird und wie Anti-Halluzination in der Public-Oberfläche wirken soll.

Verifiziert, lokal bekannt oder nur abgeleitet 4 Antworten
research wahrheit quellen halluzination verifiziert doku
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.

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.

FAQ Bereich

IT-Abdeckung, Scriptsprachen und Computersprachen

Welche technischen Bereiche im Produktkontext aktiv mitgefuehrt werden sollen.

Breite IT-Abdeckung statt enger Einzelthemen 4 Antworten
it programmiersprachen scriptsprachen linux api datenbank security
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.

FAQ Bereich

Account und Workspace

Wie der Account-Bereich als ruhige Arbeitszentrale gedacht ist.

Sessions, Presets und Rueckkehr in Arbeit 4 Antworten
konto workspace sessions preset profil ajax wissen
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.

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.

FAQ Bereich

API, Datenbanken und Crossover-Funktionen

Wie Member-API, Presets, Databank-Packs und Systembrücken zusammenarbeiten sollen.

API-Zugriff, Databanks und Preset-Crossover 4 Antworten
api member api datenbank databank preset crossover bridge
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.

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.

FAQ Bereich

Release-Prinzip und Stabilitaet

Wie neue Releases gebaut werden sollen, ohne wieder an Stabilitaet zu verlieren.

Groessere Milestones, aber kontrolliert 4 Antworten
release stabilitaet milestone no-damage overwrite
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.

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.