diff --git a/README.md b/README.md index 3e4441d..b7595b0 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,16 @@ stack-nudge

Notifications for AI coding agents.

Get a banner + sound when your agent finishes a task or pauses for your approval — step away without missing a beat.

+

+ Latest release + CI + MIT licensed + macOS 13+ +

+

+ Maintained by StackOne · + @StackOneHQ +

--- @@ -22,16 +32,17 @@ ### macOS -Download the latest release from [GitHub Releases](https://github.com/StackOneHQ/stack-nudge/releases/latest): +Download the latest release from [GitHub Releases](https://github.com/StackOneHQ/stack-nudge/releases/latest) — pick the `.tar.gz` matching your Mac's architecture (`arm64` for Apple Silicon, `x86_64` for Intel), expand, and drag `StackNudge.app` into `~/Applications/`. + +CLI shortcut (requires [`gh`](https://cli.github.com/)): ```bash -# Pick the tarball matching your Mac's architecture: -# arm64 → Apple Silicon (M1/M2/M3/M4) -# x86_64 → Intel -curl -fsSLO https://github.com/StackOneHQ/stack-nudge/releases/latest/download/stack-nudge-macos-arm64.tar.gz -tar xzf stack-nudge-macos-arm64.tar.gz -mv stack-nudge.app ~/Applications/ -open ~/Applications/stack-nudge.app +ARCH=$(uname -m) +gh release download --repo StackOneHQ/stack-nudge --pattern "stack-nudge-*-macos-${ARCH}.tar.gz*" +shasum -a 256 -c stack-nudge-*-macos-${ARCH}.tar.gz.sha256 +tar xzf stack-nudge-*-macos-${ARCH}.tar.gz +mv StackNudge.app ~/Applications/ +open ~/Applications/StackNudge.app ``` On first launch, stack-nudge runs a one-screen wizard: @@ -358,6 +369,15 @@ Swift compiled with `swiftc` directly. No Xcode, no SPM, no dependencies. Click-routing architecture (process exits after delivery, macOS re-launches on click) is adapted from [`terminal-notifier`](https://github.com/julienXX/terminal-notifier) by Eloy Durán and Julien Blanchard. +## Terms of use + +By using stack-nudge or its source code, you agree to the following: + +- Use is governed by the [MIT License](LICENSE). The software is provided "as is", without warranty of any kind. +- Participation in the project (issues, pull requests, discussions) is subject to the [Code of Conduct](CODE_OF_CONDUCT.md). +- Suspected security vulnerabilities should be reported privately per [SECURITY.md](SECURITY.md), not via public issues. +- The project is maintained by [StackOne](https://www.stackone.com/); contributions remain under the licence the contributor submits them under (MIT unless otherwise noted). + ## License -MIT +MIT — see [LICENSE](LICENSE) for the full text. Copyright © 2026 StackOne Technologies Ltd. and contributors. diff --git a/ui_improvements.md b/ui_improvements.md deleted file mode 100644 index 28c84a7..0000000 --- a/ui_improvements.md +++ /dev/null @@ -1,226 +0,0 @@ -StackNudge UI Concept — Keyboard-First Notification Hub - -🧠 Overview - -The goal is to design a keyboard-driven notification and control hub that replaces (or complements) the native macOS notification system. - -Instead of ephemeral popups, this UI acts as a persistent, interactive layer that lets users: - -* View notifications -* Navigate them quickly -* Jump back into the terminal context - -The inspiration is similar to tools like Raycast, but tailored for developer workflows and terminal integration. - -⸻ - -🎯 Core Principles - -1. Keyboard-First - -* All interactions should be possible without a mouse -* Fast open/close via global shortcut (e.g. Cmd + ) -* Navigation via: - * ↑ ↓ → move through notifications - * Enter → open/focus item - * Esc → close panel - -⸻ - -2. Persistent Notifications (Not Ephemeral) - -* Notifications do not disappear -* They form a scrollable history -* Users can revisit past events at any time - -⸻ - -3. Terminal-Centric Workflow - -* Each notification should: - * Link back to a specific terminal context - * Allow quick jump/focus into that context - -This makes the UI a bridge between system events and terminal actions. - -⸻ - -4. Lightweight but Always Available - -* The UI should feel: - * Fast - * Minimal - * Non-intrusive - -It should never interrupt flow like native notifications often do. - -⸻ - -🧩 UI Structure - -1. Entry Point (Idle State) - -A small on-screen element: - -* Could be: - * A dot - * A pill - * A subtle icon -* Positioned somewhere consistent (e.g. top-right or edge of screen) -* Displays: - * Unread count (optional) - * Subtle activity indicator - -⸻ - -2. Command Panel (Primary Interface) - -Triggered via shortcut. - -Layout: - -* Centered or anchored floating panel -* Minimal design (likely dark mode) -* Similar to a command palette - -Contents: - -* Search / filter input (optional but recommended) -* Scrollable notification list - -⸻ - -3. Notification Item Design - -Each item should include: - -* Title (short summary) -* Timestamp -* Type indicator (e.g. error, success, info) -* Optional metadata (project, process, etc.) - -States: - -* Default -* Highlighted (keyboard selection) -* Read / unread - -⸻ - -4. Interaction Model - -Navigation: - -* ↑ ↓ → move selection -* Enter → open notification -* Cmd + Enter (optional) → jump to terminal context - -On Select: - -* Either: - * Expand inline - * Or open a secondary detail view - -⸻ - -5. Detail View - -Shows: - -* Full message / logs -* Contextual information -* Action(s): - * “Open in terminal” - * “Focus session” - * “Copy output” - -⸻ - -🏗️ Future Direction: “Information Hub” - -Beyond notifications, this UI can evolve into: - -* Central place for: - * Logs - * System events - * Task status -* Internal tooling surface -* Debug / observability layer - -Essentially: a lightweight developer dashboard embedded into the OS layer - -⸻ - -⚖️ Tradeoffs - -Pros - -* Faster than native notifications -* Fully keyboard accessible -* Persistent + actionable -* Better suited for dev workflows - -Cons - -* More complex to build -* Requires careful UX tuning (“getting the flavour right”) -* Reinvents OS-level patterns - -⸻ - -❓ Open Questions - -1. Trigger Shortcut - * What should the global shortcut be? - * Should it be configurable? -2. Placement - * Should the idle UI element always be visible? - * Or only appear when there are unread notifications? -3. Search / Filtering - * Do we want fuzzy search (like Raycast)? - * Or just simple filtering? -4. Notification Types - * What kinds of events are we supporting initially? - * Logs? - * Errors? - * Background jobs? - * Deployments? -5. Terminal Integration - * What does “jump back to terminal” mean exactly? - * Focus a tab? - * Re-run a command? - * Open a specific session? -6. Multi-Project Context - * Will users have multiple projects? - * Should notifications be grouped by project? -7. Persistence - * How long should notifications be stored? - * Should there be a “clear all” or archive? -8. UI Style - * Closer to: - * Raycast (command palette)? - * Notification center (list)? - * Hybrid? -9. Mouse Support - * Strictly keyboard-first, or allow optional mouse interaction? -10. MVP Scope - -* What’s the smallest useful version? - * Just list + open? - * Or include search + grouping? - -⸻ - -🧾 Summary - -We are designing a: - -Keyboard-first, persistent notification hub that integrates tightly with terminal workflows and replaces the need for native macOS notifications. - -It should feel: - -* Fast -* Focused -* Developer-native - -