Projekte und URLs

#Projekt hinzufügen

1. Ablage → Projektordner öffnen … (⌘O / CtrlO), Projekt hinzufügen in der Seitenleiste oder Projekt hinzufügen … im Projektmenü der Titelleiste.
2. Wählen Sie, woher das Projekt kommt:
   • Auf diesem Computer: Wählen Sie einen Ordner.
   • Von GitHub / GitLab klonen: Wählen Sie eines Ihrer Repositorys (aufgelistet über Ihre Anmeldung bei gh oder glab) oder fügen Sie eine URL ein und wählen Sie den übergeordneten Ordner. Ferret klont das Repository und öffnet es.
   • Über SSH öffnen: Wählen Sie einen Host aus ~/.ssh/config. Terminal und Agents laufen auf dem entfernten Rechner; die Reviews bleiben auf diesem Computer.

Als Name wird standardmäßig der Ordnername verwendet. Fügen Sie einen bereits registrierten Ordner hinzu, wird stattdessen dieser geöffnet (unter macOS und Windows werden Pfade ohne Beachtung der Groß-/Kleinschreibung verglichen). Über das Menü in der Seitenleiste können Sie ein Projekt Umbenennen oder Aus Liste entfernen. Beim Entfernen wird der Ordner nie gelöscht.

Terminals öffnen sich im Projektordner, und Reviews werden unter <project>/.ferret/ gespeichert.

#URLs speichern

1. Öffnen Sie die Seite im integrierten Browser.
2. Klicken Sie in der Browser-Werkzeugleiste auf + (Aktuelle URL speichern). Die aktuelle URL ist bereits eingetragen.
3. Geben Sie einen Name ein und klicken Sie auf Speichern.

Jede gespeicherte URL hat unter Was Sie prüfen eine Art: App (die App, die Sie entwickeln), Design (Figma, Penpot, Canva, ein Prototyp) oder Dokument / Spezifikation (Google Docs, Notion, Confluence, eine Markdown-Spezifikation auf GitHub, ein PDF). Die Art wird aus der URL abgeleitet, und Sie können sie ändern. Siehe Designs und Dokumente prüfen, nicht nur Code.

Es werden nur URLs mit http:// und https:// akzeptiert. Wenn Sie bei einer App-URL den vorgeschlagenen Namen übernehmen, wird er aus dem Host abgeleitet:

#Bereich „Review-Ziele“

Im Feedback-Modus listet der Bereich Review-Ziele rechts alles auf, was Sie im aktuellen Projekt prüfen können. Ein Wechsel des Ziels stoppt die Aufnahme nicht. Blenden Sie den Bereich mit Darstellung → Review-Ziele ein/aus (⌘⇧K / CtrlShiftK) oder Bereich ausblenden ein und aus.

• Ziele: die gespeicherten URLs des Projekts. Unter jeder steht ein Baum der Seiten, die Sie auf dieser Site besucht haben. Besuchte Sites, die nicht gespeichert sind, erscheinen als eigene Gruppen.
• Dateien: der Projektordner. Eine Datei öffnet sich als Vorschau (Markdown und Mermaid gerendert, anderer Text schreibgeschützt), sodass Sie auch Dokumentation prüfen können. Der Stift (Im Editor öffnen) öffnet sie im Editor.

Ziele filtern filtert Ziele, Seiten und Dateien gemeinsam, mit derselben unscharfen Suche wie Gehe zu Datei …. In der Liste wechseln ↑ ↓ Enter oder 1–9 das Ziel. URL öffnen… öffnet eine einmalige URL, und In Projekt-URLs speichern behält sie.

Die Ziele stammen aus projects[].urls in settings.json (siehe das Beispiel). Jeder Eintrag braucht eine url, einen launchCommand (wird in einem Terminal ausgeführt, z. B. um eine Desktop-App zu starten) oder ein windowMatch (das aufzunehmende Fenster) und kann einen purpose haben (app, design oder doc). Die Auswahl eines Fensterziels legt es als Aufnahmequelle fest und ist daher während einer Aufnahme nicht möglich. Besuchte Seiten werden pro Projekt gespeichert, nur auf diesem Rechner (bis zu 200).

#Umgebungen öffnen und wechseln

Klicken Sie auf eine gespeicherte URL, um sie zu öffnen. Liegt die aktuelle Seite unter einer anderen gespeicherten URL, behält Ferret Pfad, Query und Hash bei und tauscht nur den Origin aus. Ein Beispiel: Auf http://localhost:3000/pricing?plan=pro öffnet ein Klick auf prd die Adresse https://example.com/pricing?plan=pro.

Der Chip, der zur aktuellen Seite passt (längstes Präfix), ist hervorgehoben. Klicken Sie mit der rechten Maustaste auf einen Chip oder verwenden Sie sein Stiftsymbol, um ihn zu bearbeiten oder zu Löschen. Wird ein Projekt geöffnet und gibt es keine vorherige URL, wird seine erste gespeicherte URL geladen.

Die Chips sind nach Art gruppiert: zuerst App-URLs, dann Designs, dann Dokumente, mit einer Trennlinie und einem Symbol für jede Art. Beim Wechsel zu oder von einem Design oder Dokument wird dessen gespeicherte URL unverändert geöffnet, ohne den Pfad zu übernehmen.

#Designs und Dokumente prüfen, nicht nur Code

Feedback muss sich nicht auf Code beziehen. Alles, was sich im integrierten Browser öffnen lässt, können Sie auf dieselbe Weise aufnehmen und mit dem Stift markieren: ein Design in Figma oder Penpot, einen Prototyp, eine Spezifikation in Google Docs oder Notion, ein Design-Dokument auf GitHub, ein PDF. Speichern Sie diese URLs vor dem Review im Projekt, neben local und dev.

1. Öffnen Sie Projekt bearbeiten … über das Menü in der Seitenleiste (oder klicken Sie in der Browser-Werkzeugleiste auf +) und wählen Sie Ziel hinzufügen.
2. Fügen Sie die URL ein. Ein Link auf figma.com wird zu Design, ein Link auf docs.google.com oder notion.so zu Dokument / Spezifikation, benannt als Figma bzw. Spec. Ist die Zuordnung falsch (zum Beispiel bei einem Prototyp auf Ihrem eigenen Server), ändern Sie die Art unter Was Sie prüfen.
3. Öffnen Sie das Ziel und melden Sie sich einmal im integrierten Browser an, falls die Site das verlangt. Der Browser behält seine Cookies zwischen den Starts, sodass Sie angemeldet bleiben.
4. Nehmen Sie wie gewohnt auf: sprechen, zeigen, auf dem Design oder dem Dokument zeichnen.

Befunde, die auf einem Design oder einem Dokument aufgenommen wurden, sind in Befunde und in feedback.md mit dieser Art gekennzeichnet, und die an den Agent gesendete Anweisung weist darauf hin. Der Agent ändert dann das Design oder das Dokument statt des Codes:

• Liegt das Dokument im Projekt (eine Markdown-Spezifikation, ein ADR), bearbeitet der Agent diese Datei.
• Kann er es nicht bearbeiten (eine Figma-Datei, ein Google-Dokument), markiert der Agent den Befund als Frage vom Agent und nennt die genaue Änderung, damit Sie sie übernehmen oder weitergeben können.

Beispiel: Beim Lesen der Preisspezifikation in Google Docs kreisen Sie die Tarif-Tabelle ein und sagen „der Pro-Tarif kostet jetzt 9.800 Yen, nicht 8.800“. feedback.md führt den Befund unter dem Ziel Spec mit Kind: document, und der Agent antwortet mit dem korrigierten Satz für die Spezifikation, statt den Code der Preisseite anzufassen. Nehmen Sie die Spezifikation und die laufende App in derselben Aufnahme auf, werden die Befunde nach Ziel getrennt, sodass der Agent zuerst die Spezifikation und danach den Code aktualisieren kann, der sie umsetzt.

Nicht gespeicherte Seiten auf figma.com, docs.google.com, notion.so und ähnlichen Hosts werden ebenfalls erkannt. Dateien im Projektordner (Markdown, Mermaid) prüfen Sie über die Liste Dateien im Bereich Review-Ziele.