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.
| Gdzie | Co rozstrzyga |
|---|---|
| Ustawienia › Cele powiadomień | samo połączenie (webhook Slacka, konto pocztowe), z nadaną nazwą |
| Ustawienia projektu › Powiadomienia | włą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
amenboprzychodzi 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.