amenbo

Amenbo 27.0.0 — powiadomienia i worktree są częścią Amenbo

To, co dotąd instalowało się jako wtyczki, jest teraz częścią samego Amenbo, a zadanie może dostać własny checkout gita. Zmiany z 24.3.0, 25.0.0 i 26.0.0 też doszły do końca w tej wersji.

To, co dotąd instalowało się jako wtyczki, jest teraz częścią samego Amenbo. Zmiany z 24.3.0, 25.0.0 i 26.0.0 też doszły do końca w tej wersji.

Wtyczki są teraz częścią Amenbo

Powiadomienia i worktree nie potrzebują już wtyczki, którą trzeba znaleźć i zainstalować. Nie ma czego instalować ani czego włączać. Jeśli miałeś je zainstalowane na wcześniejszej wersji, twoje ustawienia idą dalej, a przy pierwszym otwarciu tej wersji aplikacja raz mówi, co gdzie się przeniosło.

  • ustawienia poczty i Slacka — cele powiadomień tej maszyny i to, które projekty przez nie meldują
  • klucze użyte do parowania

Wtyczki, które miałeś zainstalowane, znikają w czasie migracji. Ekrany wtyczek i sekcja Wtyczki na pasku bocznym są usunięte. Komend amenbo plugin nie ma.

Połączenie zapisuje się na maszynie raz

To, co dzieje się z zadaniami, może iść na Slacka albo na pocztę. Połączenie zapisuje się na maszynie raz, a projekty wybierają z tego, co zapisane. Kiedy webhook się zmienia, jest jedno miejsce do poprawienia.

GdzieCo rozstrzyga
Ustawienia › Cele powiadomieńsamo połączenie (webhook Slacka, konto pocztowe), z nadaną nazwą
Ustawienia projektu › Powiadomieniawłączone/wyłączone, przez które cele wysyłać, co meldować

Zameldować można 13 zdarzeń: zadanie założone / zrobione / przypisane / przeniesione, decyzja przyjęta i odrzucona, dodany komentarz i tak dalej. Przy datach nadejście dnia i to, że dzień wypada jutro, mówi się raz dziennie.

Połączenie da się sprawdzić tam, gdzie się je wpisało. „Sprawdź połączenie” czyta kształt ustawień, a przy poczcie idzie aż do połączenia z serwerem i podania konta. „Wyślij wiadomość próbną” naprawdę ją wysyła. To, czy wysyłka działa, rozstrzyga się tam, a nie przez pierwsze powiadomienie, które nie doszło.

Tekst powiadomień wychodzi w języku wybranym w aplikacji.

Zadanie może dostać własny checkout gita

Dwie sesje na jednym drzewie roboczym mieszają sobie nawzajem niezapisane zmiany. Zadaniu można teraz wyciąć własny checkout.

eval "$(amenbo worktree start 123)"

Gdzie to trafia, jest ustalone i nikt o nic nie pyta: obok repozytorium, w <nazwa repozytorium>-worktrees/<numer zadania>, na gałęzi task/<numer zadania>. Siedzi obok katalogu projektu, a nie w środku, więc AI pracujące tam nie sięgnie do prawdziwego backlogu.

Komenda amenbo worktree finish 123 zabiera checkout i gałąź. Odmawia, dopóki są niezacommitowane zmiany albo commity, które nie doszły do zdalnego.

Poza tym o panelach

  • Pole pod panelem się zwija — zwinięte jest domyślne, a ta maszyna pamięta, czy było otwarte.
  • Enter to nowa linijka — wysyła Enter z modyfikatorem twojego systemu, a przycisk wysyłania nabiera koloru dopiero wtedy, kiedy jest co wysłać.
  • Dolny wiersz nazywa model — panel mówi, z jakim modelem rozmawia, a ponowne otwarcie aplikacji stawia go z powrotem na tym modelu.
  • Panele Codex i Gemini wracają do poprzedniej rozmowy — każdy panel to własna rozmowa.
  • Na macOS Option może być klawiszem meta — dla tych klawiszy w panelu, które chcą mety.

Skąd to wziąć

Otwórz instalator dla swojego systemu z najnowszego wydania. Prawa administratora nie są potrzebne.

  • macOS — .pkg, osobno dla Apple silicon i dla Intela (GUI i CLI jadą razem)
  • Windows — instalator .exe (GUI i CLI jadą razem)
  • Linux — GUI to AppImage; komenda amenbo przychodzi z instalatora CLI

Żeby zaktualizować: w GUI baner „jest nowsza wersja” zakłada aktualizację w miejscu. Jeśli instalowałeś samo CLI, podmieni je amenbo update --apply.

Format zapisu danych idzie w górę — pierwsze uruchomienie tej wersji migruje go, a kopia sprzed migracji zostaje zachowana automatycznie. Po migracji wcześniejsza wersja już go nie otworzy. GUI i CLI aktualizuje razem ten sam instalator, więc nie zostawiaj jednego z nich na starej wersji.

Pierwszy raz tutaj? Zajrzyj na Zacznij.