Was macht app-website?
Liefern Sie das vom Benutzer bereitgestellte Design als eigenständige statische Website mit reproduzierbaren Bun-Entwicklungs-/Build-Befehlen und explizitem Deployment-Status aus. Behalten Sie den angeforderten Hosting-Anbieter bei. Dieser Workflow stammt von AceCut (/data/swi-algo/Swi-App-Factory/Acecut/website) und GolfCut; diese Projekte sind Beispiele, keine erforderlichen Abhängigkeiten.
Eingaben ermitteln
Lesen Sie die zutreffende AGENTS.md und überprüfen Sie den Prototyp, die bestehende Website und die Deployment-Dokumentation. Identifizieren Sie den App-Namen, das Zielverzeichnis, die kanonische Domain, die echte App Store-URL und die gewünschten visuellen Änderungen. Wiederverwenden Sie vorhandenes Branding und Inhalte. Überprüfen Sie frühzeitig den Dateisystem-Schreibzugriff und die Hosting-/DNS-Authentifizierung; setzen Sie die lokale Vorbereitung fort, wenn kein Deployment-Zugriff besteht. Behandeln Sie nicht verfügbare Authentifizierung nicht als Deployment-Erfolg.
Ein Bun-Projekt vorbereiten
Initialisieren Sie für eine neue statische Website ein leeres Verzeichnis:
python3 <skill-verzeichnis>/scripts/init_site.py <app-verzeichnis>/website --slug <app-slug>
cd <app-verzeichnis>/website
bun install
Das gebündelte Starterpaket enthält die geprüften Build-/Preview-Skripte und die Vercel-Konfiguration. Behalten Sie die Werkzeuge eines bestehenden Projekts bei, wenn angemessen. public/ enthält die Quelle; scripts/build.mjs kopiert sie nach dist/; die Produktion benötigt keinen Bun-Server. Für einfaches HTML/CSS/JS wird keine Abhängigkeit benötigt. Wenn Bun nicht im PATH ist, überprüfen Sie ~/.bun/bin/bun, bevor Sie etwas installieren. Kopieren Sie kein .git, .vercel, Anmeldeinformationen oder Identität von einer anderen App.
Den Prototyp übertragen
Bevorzugen Sie einen autorisierten QuelleXport oder ein Repository. Wenn nur ein öffentlicher statischer Prototyp verfügbar ist, rufen Sie HTML ab und überprüfen Sie rekursiv gleichherkömmliche HTML-src/href und CSS-url()-Abhängigkeiten, einschließlich Feature-Seiten, Icons, SVGs und Skripte. Laden Sie mit curl herunter, wenn der Host den Python-HTTP-Client ablehnt. Zeigen Sie fehlende Ressourcen sichtbar an; speichern Sie keine Fehlertexte als Bilder. Ordnen Sie Verzeichnisrouten public/<route>/index.html zu.
Halten Sie Assets lokal. Entfernen Sie vom Hosting eingefügte Cloudflare-Challenge-Skripte und Preview-only-Metadaten aus dem abgerufenen HTML, während Sie das Anwendungs-JS erhalten. Kopieren Sie keine Service-Anmeldeinformationen oder fügen Sie ohne Anforderung Analysen hinzu. Überprüfen Sie externe Abhängigkeiten wie Google Fonts. Bewahren Sie die App-Links des Prototyps; erfinden Sie keine App Store-ID oder ersetzen Sie nicht stillschweigend die rechtlichen Bedingungen einer anderen App.
Ersetzen Sie Prototyp-Ursprünge in kanonischen URLs, Open Graph, JSON-LD, Robots und Sitemap durch den beabsichtigten Produktionsursprung. Bewahren Sie Seitenpfade konsistent. Für Schaltflächenfarbanforderungen überprüfen Sie sowohl das gerenderte Asset als auch das CSS: Ein gefülltes SVG kann einen CSS-Hintergrund verbergen. Ändern Sie nur die beabsichtigten SVG-Hintergrundpfade und bewahren Sie Logo-/Textpfade, zugängliche Namen und Link-Ziele.
Firmen-Fußzeile und rechtliche Seiten
Richten Sie für SWINK-App-Websites, die mit AceCut übereinstimmen sollen, © <jahr> SWINK AI INC., einen sichtbaren mailto:[email protected]-Kontakt-Link und funktionierende /terms- und /privacy-Links auf jeder Seite ein, einschließlich Feature-Seiten und der rechtlichen Seiten selbst. Behalten Sie das aktuelle App-Branding und den visuellen Stil bei. Verwenden Sie root-relative Assets und Navigation, damit verschachtelte Routen funktionieren; machen Sie rechtliche Links ohne JavaScript erreichbar. Lassen Sie Footer-Links auf Tablets umbrechen und verwenden Sie ein kompaktes mobiles Layout ohne horizontalen Überlauf.
Wenn der Benutzer eine Angleichung wünscht, verwenden Sie die Struktur der referenzierten App bezüglich AGB/Datenschutz und die bestätigten Firmen-/Kontaktdaten, passen Sie dann App-Namen, tatsächliche Funktionen, Daten, kanonische URLs und Cross-Links an. Übertragen Sie nicht blind den Analyseanbieter, das Upload-Verhalten, Speicher-/Aufbewahrungszusagen oder Einstellungen einer anderen App. Überprüfen Sie verfügbare Produktbelege für solche Behauptungen; lassen Sie unbestätigte Details weg, anstatt sie zu erfinden. Halten Sie AGB und Datenschutz als lesbare eigenständige Seiten, fügen Sie beide zur Sitemap hinzu und überprüfen Sie saubere URLs in lokalen Werkzeugen und Vercel.
Überprüfen Sie bei Footer-/Rechtsänderungen alle betroffenen Seiten in Desktop-, Tablet- und schmalen Mobilbreiten; überprüfen Sie Firmentext, mailto-Ziel, beide rechtlichen Links, lesbaren Text, keinen Überlauf und die mobile Navigation. Bewahren Sie die angeforderten Download-Schaltflächenfarben. Nach dem Pushen überprüfen Sie das neue Produktions-Deployment und rufen Sie die echten /terms und /privacy über HTTPS ab, bevor Sie sie als live melden.
Bauen und überprüfen
bun run build
bun run preview
Der lokale Server unterstützt Verzeichnisindex-Routen und .html-saubere URLs, GET und HEAD, und gibt 404 für fehlende Dateien zurück. Validieren Sie jede Seite und jedes lokale Asset über HTTP; bestätigen Sie Sitemap und kanonische URLs. Überprüfen Sie Desktop- und schmale Mobilbreiten (z.B. 1440, 768, 390 und 320), Überlauf, geladene Bilder, Browser-Fehler, Menüs, Tabs/Tastatursteuerung, FAQ, Filter und Download-Ziele, soweit zutreffend. Erstellen Sie Überprüfungs-Screenshots außerhalb von public/. Wenn Farbe durch ein SVG dargestellt wird, überprüfen Sie dessen Pfade oder Screenshot-Pixel sowie das berechnete CSS.
GitHub-Veröffentlichung und Maschinenzugriff
Auf der SWI-Maschine wurde AceCut unter dem Linux-Benutzer ubuntu (GitHub-Identität CC-AIMI) mit dem vorhandenen GitHub-CLI-Login gepusht. Bestätigen Sie die aktuelle Identität und Repository-Schreibberechtigung mit gh repo view <besitzer>/<repo> --json viewerPermission,defaultBranchRef,isEmpty, bevor Sie sich auf diesen Präzedenzfall verlassen. Ein Netzwerk-/Proxy-Fehler ist kein Beweis für einen ungültigen Login. Wenn Git trotz eines funktionierenden gh-Logins nach einem Benutzernamen fragt, verwenden Sie einen pro Befehl festgelegten Credential Helper im selben authentifizierten Linux-Konto: git -c credential.helper='!gh auth git-credential' push origin <branch>. Dies verwendet den vorhandenen Login wieder, ohne dessen Token offenzulegen oder die globale Git-Konfiguration zu ändern. Kopieren Sie keine Anmeldeinformationen zwischen Konten oder legen Sie keine Passwörter/Tokens in dieses Skill, Shell-Argumente, Quelldateien oder Logs.
Wenn ein Benutzer ein Administratorkonto autorisiert, um ein Unix-Berechtigungsproblem zu lösen, überprüfen Sie id und getfacl, und gewähren Sie nur den benötigten Projektzugriff (z.B. setfacl -m u:<ausfuehrer>:rwx,d:u:<ausfuehrer>:rwx <projekt>). Bewahren Sie Besitzer/Gruppe und nicht verwandte Berechtigungen. Ein Administrator-Login authentifiziert nicht Vercel oder GoDaddy.
Wenn ein explizit angefordertes Repository bereits existiert, klonen Sie es zuerst und bewahren Sie seine Historie; forcieren Sie keinen unabhängigen Initial-Commit. Platzieren Sie die Website-Dateien im Repository-Stammverzeichnis, nicht in einer weiteren website/-Ebene. Schließen Sie .git, .vercel, dist, node_modules, Validierungs-Screenshots und Geheimnisse beim Übertragen vorbereiteter Quellen aus. Wenn Sie über ein anderes autorisiertes Linux-Konto veröffentlichen, verwenden Sie einen temporären Checkout, der diesem Konto gehört, und gewähren Sie nur erforderlichen Lesezugriff auf die Quelle. Konfigurieren Sie den beabsichtigten Autor des Repositorys lokal, überprüfen Sie die bereitgestellten Dateien, committen Sie, pushen Sie in den beabsichtigten Branch und überprüfen Sie den remote SHA. Halten Sie den Haupt-Arbeits-Checkout danach synchronisiert.
Für ein eigenständiges Repository wie diifan/golfcut-website muss Vercel dieses Repository mit Root-Verzeichnis ./ importieren. Ein GitHub-Push allein erstellt kein Vercel-Projekt.
Vercel und DNS
Das Starterpaket verwendet Framework null (Dashboard: Andere), bun install, bun run build, Ausgabe dist, cleanUrls: true, trailingSlash: false. Setzen Sie in einem eigenständigen Website-Repository das Vercel-Root-Verzeichnis auf ./; in einem App-Monorepo verwenden Sie website/. Die GitHub-Integration ist optional, wenn eine authentifizierte Vercel-CLI/API direkt deployen kann. Folgen Sie dem autorisierten Veröffentlichungsumfang des Benutzers, ohne eine weitere Genehmigungsstufe hinzuzufügen.
Überprüfen Sie das authentifizierte Konto/Team und das vorhandene Projekt, bevor Sie ein neues erstellen oder verknüpfen. Wenn ein CLI-Login erforderlich ist, führen Sie bun x vercel login aus und senden Sie die aktuelle Geräteautorisierungs-URL an den Benutzer; halten Sie den Prozess am Leben, während Sie unabhängige Arbeiten durchführen. bun x funktioniert auch, wenn der bunx-Shim fehlt. Behalten Sie sich vor, den Login zu melden, bis die CLI ihn bestätigt. Überprüfen Sie nach dem Login verfügbare Teams und das AceCut-Projekt, wählen Sie denselben beabsichtigten Bereich, erstellen/verknüpfen Sie das neue App-Projekt, verbinden Sie sein genaues GitHub-Repository und deployen Sie dann. Bevorzugen Sie ein verbundenes Vercel-Plugin, wenn es diese Fähigkeiten bereitstellt. Verwenden Sie keine abgelaufenen Geräte-Codes oder nehmen Sie an, dass ein vorgeschlagenes Plugin verbunden ist. Verwenden Sie niemals die Projekt-ID einer anderen App wieder. Deployen Sie die erstellte Website und überprüfen Sie die zurückgegebene Deployment-URL. Fügen Sie für eine angeforderte app.goswie.com diese genaue Domain zu ihrem Vercel-Projekt hinzu und erhalten Sie dann die aktuelle DNS-Empfehlung des Projekts. Erstellen/aktualisieren Sie beim autoritativen DNS-Anbieter (AceCut dokumentiert GoDaddy) nur den angeforderten App-Eintrag, normalerweise CNAME-Host app. Verwenden Sie das von Vercel zurückgegebene Ziel, kein geratenes oder kopiertes AceCut-Ziel. Bewahren Sie nicht verwandte Einträge, insbesondere @, www, MX und Nameserver. Lösen Sie einen Besitz-/Konflikt, bevor Sie einen vorhandenen, nicht verwandten Eintrag ersetzen. Fügen Sie nur einen angeforderten TXT-Überprüfungseintrag hinzu, wenn Vercel dies erfordert.
Überprüfen Sie öffentliches DNS, Vercel-Domain-Status, HTTPS und die deployeden Seiten. Wenn Anmeldeinformationen fehlen, schließen Sie den Build ab und dokumentieren Sie die genaue verbleibende Kontoaktion; unterscheiden Sie zwischen vorbereiteter Konfiguration, abgeschlossenem Deployment und verifizierter Domain. Bezeichnen Sie eine geplante Domain niemals als live.
Aktuelle offizielle Referenzen (bei Deployment-Arbeiten konsultieren):
Verifizierte CLI-Sequenz
GolfCut wurde mit Vercel CLI 65.4.0 deployed. Verwenden Sie nach einem authentifizierten Login die aktuelle --help, wenn sich Flags unterscheiden. Ersetzen Sie den verifizierten Bereich, das Projekt und das Repository; der tatsächliche SWI-Bereich, der für AceCut und GolfCut verwendet wurde, ist diifans-projects.
bun x vercel teams list
bun x vercel project list --scope <bereich>
bun x vercel project create <projekt> --scope <bereich>
bun x vercel link --yes --project <projekt> --scope <bereich>
bun x vercel git connect --yes --scope <bereich>
bun x vercel project update <projekt> --framework other --build-command 'bun run build' --install-command 'bun install' --output-directory dist --yes --scope <bereich>
bun x vercel --prod --yes --scope <bereich>
bun x vercel domains add <app-domain> <projekt> --scope <bereich>
bun x vercel domains verify <app-domain> --scope <bereich>
Führen Sie diese vom Website-Checkout mit der korrekten Git-Remote aus. Überspringen Sie die Erstellung, wenn das passende Projekt existiert. git connect --yes verwendet diese Remote; ohne --yes kann die CLI im Agentenmodus bei einem Bestätigungs-Prompt beenden, ohne tatsächlich zu verbinden. link kann .env.local mit einem OIDC-Token und .vercel/ erstellen; lassen Sie beide ignoriert. Drucken oder committen Sie sie niemals.
Senden Sie eine neu generierte Geräte-Login-URL sofort, behalten Sie den Login-Prozess und warten Sie auf dessen expliziten Erfolg. Wenn ein Benutzer einen ungültigen/abgelaufenen Code meldet, stoppen Sie den alten Login, geben Sie einen neuen aus und halten Sie die Runde für die Autorisierung aktiv; geben Sie nicht immer wieder die veraltete URL zurück.
Ein READY-Deployment und ein Alias für eine benutzerdefinierte Domain beweisen nicht, dass das öffentliche DNS funktioniert. Testen Sie die öffentliche <projekt>.vercel.app-URL ohne Authentifizierung sowie die angeforderte Domain. domains verify gibt die genaue empfohlene CNAME zurück; notieren Sie diesen Wert für den Benutzer, falls er das DNS verwaltet. Halten Sie die öffentliche Vorschau verfügbar, während das DNS aussteht. Wenn Git verbunden ist, sollten spätere Pusher ein Deployment auslösen; überprüfen Sie den Deployment-Status, wenn Sie behaupten, dass ein bestimmter neuer Commit live ist.
Übergabe
Dokumentieren Sie Quellursprung, Befehle, Build-Ausgabe, Validierungsnachweise und verbleibende Einschränkungen in der Website-README. Halten Sie generierte Ausgaben, lokale Validierungsartefakte, Umgebungsdateien und Anbieter-Anmeldeinformationen aus Git heraus. Melden Sie die tatsächliche Live-URL nur nach erfolgreichem Deployment; andernfalls geben Sie das fertige Projekt und den genauen Blocker an.