diff --git a/README.md b/README.md
index 3e4441d..b7595b0 100644
--- a/README.md
+++ b/README.md
@@ -2,6 +2,16 @@
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.
+
+
+
+
+
+
+
+ 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
-
-