Cyrus-terra/qilin-fit

Kylin / QAX Frontend-Kompatibilitätsentwicklung

Nutzungsprinzipien

Behandle Kompatibilität als Einschränkung dieser Implementierung – nicht als nachträgliches „Farbanpassen“. Dieses Skill gilt für Neuentwicklung, Fehlerbehebung, Dependency-Updates und Code-Reviews; es setzt kein bestimmtes Framework voraus. Es befasst sich nur mit den Risiken der betreffenden Aufgabe, nicht mit einer bedingungslosen Umschreibung des gesamten Projekts.

Es kann nicht garantiert werden, dass alle QAX-Versionen abgedeckt werden. Produktnummern, Vertriebskanäle und Chromium-Kernelversionen unterscheiden sich; derselbe Kernel kann auf verschiedenen CPUs, Treibern und Unternehmensrichtlinien unterschiedlich funktionieren. Unbekannte Informationen müssen als „zu bestätigen“ markiert werden; keine gefälschten Validierungsaufzeichnungen erstellen.

1. Zuerst den Support-Vertrag festlegen

1. Lies vorhandene Projektanweisungen, Lockfiles, Build-Konfigurationen, Kompatibilitätstests und Support-Bereiche. Behalte Benutzeränderungen bei.
2. Sammle vom Benutzer, aus der Browser-Seite „Über“ und aus assets/browser-probe.html: Produktname, vollständige Version, Vertriebskanal, vollständige Chromium-Version, Kylin-Version/SP, CPU-Architektur, DPR/Zoom, Schriftarten/GPU, wichtige Unternehmensrichtlinien. Der User-Agent dient nur als Hinweis, nicht als Nachweis des tatsächlichen Kernels.
3. Erstelle oder aktualisiere die vorhandene Support-Matrix des Projekts; falls keine vorhanden ist, kann assets/support-matrix.example.json verwendet werden. Fülle geschäftskritische Funktionen, minimale tatsächliche Kernel, echte Geräte- und Degradations-Abnahmekriterien aus. Keine geschäftlichen Gerätedaten im Skill-Installationsverzeichnis speichern.
4. Bei unbekannter Baseline zuerst nachfragen, nicht blind Chromium 102 annehmen. Wenn der Benutzer eine vorzeitige Entwicklung wünscht, kann eine konservative Baseline vorläufig festgelegt werden, muss aber als provisional / unbestätigt markiert werden. Nicht „alle Versionen kompatibel“ behaupten.
5. Lese Browser-Matrix. Verschiedene Vertriebskanäle und Architekturen getrennt abnehmen; die niedrigste Baseline und höhere Versionen müssen abgedeckt sein. Nicht nur das neueste Chrome testen, um QAX zu repräsentieren.

2. Read-Only-Audit: Minimaländerungen bestimmen

• Lese den tatsächlichen Quellcode und die Produktions-Build-Konfiguration, um CSS-Tools, UI-Library, Browser-/Serverseitige Einstiegspunkte, Drittanbieterpakete und Deployment-Methode zu ermitteln.
• Wähle Referenzen basierend auf der Änderung aus; nicht jedes Mal alle Dateien laden:

Aufgabe	Erforderliche Lektüre
Styles, Tailwind, Layout, Themes, Modals	CSS und Layout
JS/TS, Syntax-Transpilation, Dependencies, Web APIs	JavaScript und Build
Schriftarten/IME, Dateien, PDF, Berechtigungen, Netzwerk, CPU/GPU	Kylin-Plattform und Auslieferung
Tests, Screenshots, Release-Abnahme, Datengrenzen	Validierung und Abnahme
Feature-Support oder Versionsbasis überprüfen	Quellen und Evidenzlevel

• Führe den Checker vom tatsächlichen Skill-Installationspfad aus; <skill-dir> steht für das Verzeichnis, in dem sich SKILL.md befindet – ersetze es durch den bestätigten Pfad, nicht den Platzhalter kopieren:

python3 "<skill-dir>/scripts/compat_audit.py" ./src --min-chromium 102

Verwende 102 nur, wenn der Support-Vertrag auf 102 festgelegt ist. Bei unbestimmter Baseline --min-chromium weglassen; die Ausgabe markiert dann unknown. Pfad entsprechend dem realen Projekt ersetzen. Der Checker ist read-only, benötigt keine Drittanbieter-Abhängigkeiten und ändert keinen Code. Er ist eine lexikalische Kandidatenerkennung, kein AST-, CSS-Compiler oder Kompatibilitätszertifikat.

3. Implementierungsregeln

CSS

• Bevorzuge stabile Pfade: normale hex/rgb/hsl, traditionelles transform, layout mit Fallback. Moderne Features nur verwenden, wenn das Ziel sie unterstützt oder progressive Enhancement nachweisbar ist.
• Für Baseline 102: Besonders prüfen auf :has(), Container-Queries, neue Viewport-Einheiten, unabhängige Transformationen, moderne Farben, natives Nesting, Popover und von Tailwind generierten Code. Support-Schwellen und Alternativen siehe CSS-Referenz.
• Tailwind v4 offizielles Minimum Chrome 111; 102 ist nicht unterstützt. Nicht behaupten, dass Palette-Patches, Autoprefixer oder JS-Target-Einstellung das Problem der gesamten v4-Kompatibilität lösen. Stattdessen unterstützte Lösungen oder validierte Build-Transformationen vorschlagen. Migration/Downgrade von Abhängigkeiten erst nach Bestätigung durchführen.
• Der Fallback von var() ersetzt keine moderne Farb-Fallback-Logik; CSS.supports() ersetzt kein pixelgenaues Rendering. Prüfe jeweils Parsing, berechnete Werte und visuelles Ergebnis separat.
• Bei Änderungen der Modal-Positionierung: Animations- und Drag-Transform-Komposition beibehalten. Überprüfe Overlay, Fokus, Scrollen, Tastatur, Portal und Stacking-Context – nicht nur einen zentrierten Screenshot.

JS / Abhängigkeiten

• Unterscheide zwischen Syntax-Transpilation, Polyfills für Built-in-Objects und Web-APIs, die Berechtigungen oder native Plattformunterstützung benötigen. TypeScript target, lib und Build-target können sich nicht gegenseitig ersetzen.
• Konfiguriere für die Browser-Auslieferung das reale minimale Kernel-Level. Prüfe Abhängigkeiten, dynamische Chunks, Worker, Drittanbieter-Skripte und CSS-Artefakte. Node-Server-APIs nicht als Browser-APIs verwenden.
• Neue APIs am Einstiegspunkt mit Feature-Detection prüfen und geschäftlich akzeptable Fallbacks bereitstellen. Syntax-Parsing-Fehler treten vor der Detektion auf; sie können nicht durch if-Blöcke um neue Syntax herum ersetzt werden.
• Keine blanket-Deaktivierung bereits unterstützter Features (z. B. Optional Chaining). Keine blanket-Polyfills. Aus Sicherheitsgründen: CSP, Zertifikatsvalidierung, Sandboxing oder andere Sicherheitsmaßnahmen nicht deaktivieren.

Plattform / Daten

• Abdecken: fehlende Schriftarten, IME-Kompositionsereignisse für Chinesisch, Architekturunterschiede, GPU, Downloads, Drucken, Dateinamen, Proxy/Zertifikate, Offline-Deployment und Unternehmensrichtlinien.
• Bei externen/AI-Daten: Daten am Eingang anhand des tatsächlichen Schemas validieren und explizite Fehler-/Fehlstatus anzeigen. Keine unbekannten Bewertungen stumm durch gültige Werte ersetzen. Keine bestimmte Validierungsbibliothek erzwingen. Änderungen, die nichts mit dem Browser zu tun haben, nicht ausweiten.

4. Validierungsreihenfolge

1. Quellcode-Risikoscans, vorhandene Unit-Tests und Lint; Gründe für nicht gescannte Verzeichnisse, False Positives und manuelle Ausnahmen festhalten.
2. Produktions-Build; das tatsächlich ausgelieferte CSS/JS scannen (mit --include-build, dabei bestätigen, dass es sich nicht um Source-Maps oder Node-Server-Pakete handelt). Tatsächliche Ausgaben der Transformation/Degradierung dokumentieren – nicht allein aus der Konfiguration auf die Wirksamkeit schließen.
3. Offline-Probe im Zielbrowser öffnen, visuelle Bereiche manuell prüfen, dann kritische Abläufe im echten Projekt durchgehen. Die Probe ersetzt keine Projekttests; keine Kontodaten oder geschäftlichen Eingaben sammeln.
4. Gegen die niedrigste Baseline, vorhandene Versionen und die aktuelle Version auf einem echten Kylin-Terminal die unter Referenzdokumenten beschriebenen Funktions-/Screenshot-/Tastatur-/IME-/Zoom-/Druckabnahmen durchführen. Normales Chrome, Playwrights aktuelles Chromium oder gefälschter User-Agent ersetzen kein echtes Zielgerät.
5. Wenn kein echtes Gerät, keine Installationsberechtigung oder fehlgeschlagener Build vorliegt, Blockaden und nicht validierte Punkte explizit auflisten. Keine gefälschten Screenshots oder Erfolgsmeldungen generieren.

# Beispiel: Durch das tatsächliche Build-Verzeichnis des Projekts ersetzen
python3 "<skill-dir>/scripts/compat_audit.py" ./dist --include-build --min-chromium 102 --format json
# Optional: CI-Gate für alle Kandidatenrisiken einrichten; zuerst False Positives und nachweisbares progressive Enhancement behandeln
python3 "<skill-dir>/scripts/compat_audit.py" ./src --min-chromium 102 --fail-on warning

5. Ausgabeformat

Kurze Zusammenfassung:

• Support-Vertrag: Tatsächliche Version/Architektur, minimaler Kernel; unknown/provisional muss vermerkt sein.
• Änderungen und Begründung: Problem, Ort, Degradierungs-/Transformationsweise; bei Code-Verweisen path:line verwenden.
• Validierungsergebnisse: Quellcode, Artefakte, normaler Browser, echte Kylin-Geräte jeweils mit pass/fail/not-run – nicht zu einem einzelnen „bestanden“ zusammenfassen.
• Restrisiken: Nicht validierbare Versionen, Richtlinien-/Hardwarebeschränkungen, vom Benutzer zu treffende Abwägungen.

Die Skill-Beschreibung dient der automatischen Zuordnung; falls bei jeder relevanten Aufgabe eine Triggerung erforderlich ist, muss die Projektanweisung des verwendeten Agenten explizit das Laden dieses Skills vor der entsprechenden Entwicklung verlangen. Das Skill selbst kann die Host-Erkennungsmechanismen nicht ersetzen, keine Berechtigungen umgehen oder den Modellaufruf erzwingen.