Add changelog entry for alpha.5 chromium backend release

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -0,0 +1,92 @@
+name: Bug report
+description: Report incorrect behavior, regressions, or build/install failures
+title: "[bug] "
+labels:
+  - bug
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting an issue. Please provide enough detail to reproduce the problem.
+  - type: dropdown
+    id: issue_area
+    attributes:
+      label: Area
+      description: Which area best fits this issue?
+      options:
+        - distro-compat
+        - integration
+        - icons
+        - architecture/runtime
+        - ci
+        - docs
+        - other
+    validations:
+      required: true
+  - type: input
+    id: deskify_version
+    attributes:
+      label: Deskify version
+      description: For example `v0.1.0-alpha.2` or commit SHA
+      placeholder: v0.1.0-alpha.2
+    validations:
+      required: true
+  - type: input
+    id: distro
+    attributes:
+      label: Linux distribution
+      description: Include distro + version
+      placeholder: Fedora 41 / Arch Linux / Ubuntu 24.04
+    validations:
+      required: true
+  - type: input
+    id: desktop_environment
+    attributes:
+      label: Desktop environment / session
+      description: Include DE/WM and Wayland/X11 if relevant
+      placeholder: GNOME (Wayland), KDE Plasma (X11), Hyprland
+  - type: textarea
+    id: command
+    attributes:
+      label: Command used
+      description: Exact command that triggered the issue
+      placeholder: |
+        deskify build --url "https://example.com" --name "Example"
+      render: bash
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+    validations:
+      required: true
+  - type: textarea
+    id: actual
+    attributes:
+      label: Actual behavior / error output
+      description: Paste the relevant error message or describe what happened
+    validations:
+      required: true
+  - type: textarea
+    id: repro_steps
+    attributes:
+      label: Steps to reproduce
+      placeholder: |
+        1. Install prerequisites...
+        2. Run `deskify ...`
+        3. Observe ...
+    validations:
+      required: true
+  - type: checkboxes
+    id: checks
+    attributes:
+      label: Before submitting
+      options:
+        - label: I checked the README/known limitations and prerequisites
+          required: true
+        - label: I included distro/environment details
+          required: true
+        - label: I included the exact command and error output
+          required: true
+

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Deskify README
+    url: https://github.com/spalencsar/deskify/blob/master/README.md
+    about: Check installation requirements, known limitations, usage examples, and release notes first.
+  - name: Contributing Guide
+    url: https://github.com/spalencsar/deskify/blob/master/CONTRIBUTING.md
+    about: Read local checks, smoke-test guidance, and contribution expectations before opening work-related issues/PRs.
+  - name: Maintainer Notes (Labels / Triage)
+    url: https://github.com/spalencsar/deskify/blob/master/docs/maintainer-notes.md
+    about: Reference label categories and alpha-phase triage conventions.

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -0,0 +1,72 @@
+name: Feature request
+description: Suggest a user-facing improvement, integration idea, or architectural direction
+title: "[feature] "
+labels:
+  - enhancement
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the suggestion. Feature requests are most helpful when they describe the problem first, then the proposed solution.
+  - type: dropdown
+    id: request_area
+    attributes:
+      label: Area
+      description: Which area best fits this request?
+      options:
+        - integration
+        - icons
+        - architecture/runtime
+        - distro-compat
+        - docs
+        - ci
+        - other
+    validations:
+      required: true
+  - type: checkboxes
+    id: design_signal
+    attributes:
+      label: Design impact
+      description: Tick this if the request changes long-term project direction
+      options:
+        - label: This likely affects architecture or long-term product direction (`design decision`)
+          required: false
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem statement
+      description: What problem are you trying to solve?
+      placeholder: |
+        I want to ...
+        The current limitation is ...
+    validations:
+      required: true
+  - type: textarea
+    id: proposed_solution
+    attributes:
+      label: Proposed solution
+      description: Describe the behavior/API/CLI change you would like to see
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: What are you doing today, or what other options did you consider?
+      placeholder: PWAs, Flatpak web apps, manual `.desktop` entries, etc.
+  - type: textarea
+    id: scope
+    attributes:
+      label: Scope / rollout thoughts (optional)
+      description: If relevant, suggest MVP scope or phased rollout
+      placeholder: Could start as..., later evolve into...
+  - type: checkboxes
+    id: checks
+    attributes:
+      label: Before submitting
+      options:
+        - label: I described the problem, not only the implementation idea
+          required: true
+        - label: I checked existing issues/discussions for duplicates
+          required: true
+

.github/workflows/release.yml

@@ -4,6 +4,7 @@ on:
   push:
     tags:
       - "v*"
+  workflow_dispatch:
 
 permissions:
   contents: write

CHANGELOG.md

@@ -7,6 +7,47 @@ and this project follows early MVP/alpha versioning with tags like `v0.1.0-alpha
 
 ## [Unreleased]
 
+## [v0.1.0-alpha.5] - 2026-02-23
+
+### Added
+- `chromium` compatibility backend via `--backend chromium` using an installed Chromium-based browser in app mode (no local Tauri build for generated apps)
+- `build` / `update` flags for Chromium backend selection and runtime control:
+  - `--backend <tauri|chromium>`
+  - `--browser-bin <PATH>`
+  - `--profile-scope <isolated|shared>`
+- Chromium app install flow with XDG `.desktop` launchers and per-app metadata (`X-Deskify-Backend=chromium`)
+- Optional isolated Chromium profiles under `~/.local/share/deskify/profiles/<id>`
+- `doctor` now reports whether a Chromium-based browser is available in `PATH`
+
+### Changed
+- `update <id>` now keeps the internal app ID stable even when the display name changes
+- `list` now derives the internal ID from the `.desktop` filename (works for both Tauri and Chromium backends)
+- `remove` now also cleans up Chromium profile directories (when present)
+- `update` keeps Chromium isolated profiles by default to preserve sessions/cookies during reinstall
+
+### Fixed
+- Tauri wrapper generation now consistently uses the existing internal ID for generated app identifiers (prevents accidental ID drift during updates)
+- `.desktop` command generation for Chromium backend now escapes arguments (URLs / user agents with spaces or special characters)
+
+### Documentation
+- README now documents backend modes (`tauri` vs `chromium`) and recommends `--backend chromium` for sites that fail in the system WebView backend
+- Added Chromium backend usage examples (`--browser-bin`, `--profile-scope`) and updated compatibility notes
+
+### Added
+- `build --no-decorations` option to create frameless windows (`decorations: false`) for kiosk/dashboard-style setups
+- README screenshots for KDE/Arch showing launcher integration, running app window, and `deskify list` workflow
+
+### Fixed
+- Icon handling now normalizes downloaded and custom icons to RGBA PNG before Tauri build (prevents `icon ... is not RGBA` build failures)
+
+## [v0.1.0-alpha.2] - 2026-02-23
+
+### Fixed
+- Resolved a CI failure caused by Clippy (`items_after_test_module`) by moving the test module to the end of `src/main.rs`
+
+### Changed
+- No functional CLI behavior changes; this is a release/CI correctness follow-up to `v0.1.0-alpha.1`
+
 ## [v0.1.0-alpha.1] - 2026-02-23
 
 ### Added

CONTRIBUTING.md

@@ -46,6 +46,10 @@ cargo test
 cargo check
 ```
 
+## Maintainer Notes (Repo Meta / Triage)
+
+Maintainers can use `docs/maintainer-notes.md` for the current label strategy and issue triage conventions during the alpha phase.
+
 ## Manual Smoke Test (Recommended for Behavior Changes)
 
 If your change affects build/install/list/remove behavior, run a quick smoke test:

Makefile

@@ -0,0 +1,5 @@
+REPO ?= spalencsar/deskify
+
+.PHONY: labels
+labels:
+	./scripts/setup-github-labels.sh $(REPO)

README.md

@@ -1,8 +1,8 @@
 <h1 align="center">deskify</h1>
 
 <p align="center">
-  <b>A blazing fast, lightweight Nativefier alternative written in Rust & Tauri.</b><br>
+  <b>Turn websites into first-class Linux desktop applications with Rust, Tauri, and the system WebView.</b><br>
-  Instantly turn any website or web app into a native, standalone Linux desktop application.
+  Build native-feeling, standalone web app wrappers with CLI-first Linux integration.
 </p>
 
 <p align="center">
@@ -12,32 +12,129 @@
   <img src="https://img.shields.io/badge/Status-Alpha-yellow?style=flat-square" alt="Alpha status" />
 </p>
 
+<p align="center">
+  <img src="docs/assets/chat-kde.png" alt="Deskify app window running chat.com on KDE Plasma" width="49%" />
+  <img src="docs/assets/chat-launcher-kde.png" alt="Deskify app visible in KDE launcher" width="49%" />
+</p>
+
+<p align="center">
+  <img src="docs/assets/deskify-list-terminal.png" alt="deskify list terminal output" width="80%" />
+</p>
+
+<p align="center"><sub>Screenshots: KDE Plasma on Arch Linux (alpha MVP workflow).</sub></p>
+
 ---
 
-## ⚡ Why deskify?
+## Why Deskify Exists
 
-The original [Nativefier](https://github.com/nativefier/nativefier) project (Node.js/Electron) was an incredible tool, but it is now unmaintained and deprecated. Furthermore, packaging an entire Chromium V8 engine for *every single web app* you create consumes massive amounts of RAM and disk space.
+Web apps are now core tools, but Linux desktops still treat them like second-class citizens.
 
-**deskify** solves this by leveraging [Tauri](https://tauri.app/). Instead of bundling a heavy browser engine, it uses your native system webview (e.g., `webkit2gtk` on Linux). 
+- Electron-based wrappers solve distribution, but often at high RAM/disk cost.
+- PWAs help in some browsers, but desktop integration is inconsistent across environments.
+- The original [Nativefier](https://github.com/nativefier/nativefier) proved the need, but it is now unmaintained.
 
-## 🚧 Project Status (Alpha / Early MVP)
+`deskify` takes a Linux-first approach: it turns a website into a native-feeling desktop app using [Tauri](https://tauri.app/) and the system webview (for example `webkit2gtk`) instead of bundling a full browser engine per app.
+
+## Problem Fit (Why Deskify vs. Other Approaches)
+
+Deskify is optimized for Linux users who want native desktop integration and CLI-friendly automation for web apps, without shipping a bundled browser runtime per app.
+
+The comparison below is intentionally rough and practical (not benchmark marketing). It describes tradeoffs, not winners in every category.
+
+| Approach | Runtime model | Desktop integration | Automation / scripting | Isolation / sandbox | Setup complexity | Offline capability |
+| --- | --- | --- | --- | --- | --- | --- |
+| Electron / Nativefier | Bundled Chromium per app | Good | Low to medium | Per-app process, app-bundled runtime | Easy to medium | Depends on the site |
+| PWA | Browser runtime | Limited / browser-dependent | Low | Shared browser context | Very easy | Depends on browser + site |
+| Flatpak web app models | Sandbox-oriented runtime model | Good | Limited | Strong sandbox model | Medium | Depends on runtime + site |
+| **Deskify** | System WebView | Native (`.desktop`, icons, WMClass) | **High (CLI-first)** | Medium (shared system WebView security model) | Medium (Tauri prerequisites) | Depends on the site |
+
+### Deskify Focus (Today)
+
+Deskify focuses on:
+
+- system-native Linux desktop integration
+- minimal runtime overhead by relying on the system WebView
+- automation-friendly CLI workflows
+- straightforward local install/remove lifecycle management
+
+Deskify intentionally does not aim to:
+
+- replace full browser sandbox products
+- provide a cross-platform abstraction layer
+- ship bundled browser runtimes per generated app
+
+## How Deskify Works Today (Alpha / MVP)
 
 `deskify` is ready for public use and testing as an **early MVP**, but it is **not production-hardened yet**.
 
 - **Platform scope:** Linux only
-- **Build model:** `deskify` compiles a local Tauri wrapper app on your machine
+- **Current architecture:** one generated Tauri wrapper project per app
-- **First build can take a while:** Rust crates + Tauri build steps may need to compile
+- **Build model:** `deskify` compiles the wrapper locally on your machine
-- **Test coverage:** currently limited (core behavior is implemented, but automated coverage is still growing)
+- **Why this MVP design:** simpler debugging, isolated failures, low contributor complexity
+- **Tradeoff:** build time and distro-specific setup issues become user-facing
+- **Test coverage:** currently limited (core behavior is implemented, automated coverage is growing)
+
+### MVP Architecture (Today)
+
+```mermaid
+flowchart TD
+    A[deskify CLI] --> B[Generate temporary Tauri wrapper project]
+    B --> C[Fetch or copy icon]
+    C --> D[Write tauri.conf.json + source files]
+    D --> E[Run cargo tauri build locally]
+    E --> F[Install binary to local executable dir]
+    F --> G[Install icon + .desktop entry]
+    G --> H[Launch from Linux app menu]
+```
 
 ### Known Limitations
+
 - Requires Tauri/Linux system dependencies to be installed locally before `deskify build`
 - Generated app build success can vary by distro/system setup (WebKitGTK/Tauri prerequisites)
+- Some modern sites fail or degrade in the system WebView backend (`tauri`) due to engine/runtime differences
 - No official cross-platform support (Windows/macOS) yet
 - GitHub Releases / binary automation for `deskify` itself may lag behind source updates during early MVP
+- DRM/protected-media services may not work reliably in the system WebView backend even if they work in a full browser (depends on WebView/DRM support)
 
-### 🌟 Features
+## Where Deskify Is Going
-- **Extremely Lightweight:** Generated binaries are tiny (~4-6 MB) and RAM consumption is minimal.
+
+Deskify aims to make web applications **first-class Linux desktop applications**.
+
+Planned evolution (direction, not promise):
+
+- Shared runtime model for multiple apps
+- Per-app config and icon installs without full rebuilds
+- Stronger Linux desktop integration (deployment, automation, kiosk/admin workflows)
+- Better distro compatibility guidance and troubleshooting
+
+The current per-app build approach is intentional for the MVP. The goal is to keep it simple now while making the longer-term direction visible.
+
+### Planned Evolution (Concept)
+
+```mermaid
+flowchart TD
+    A[deskify CLI] --> B[deskify runtime binary]
+    A --> C[App config files]
+    A --> D[Icons + .desktop entries]
+    C --> E[apps/chatgpt.json]
+    C --> F[apps/home-assistant.json]
+    B --> G[Load app config at launch]
+    G --> H[Open site in system webview]
+    D --> I[Linux app menu integration]
+```
+
+## Why Not Just Use Flatpak Web Apps / PWAs / Electron?
+
+The table above covers the technical tradeoffs in more detail. In practice, `deskify` is most useful when you want:
+
+- a CLI-first workflow for repeatable installs and automation
+- Linux-native desktop integration (`.desktop`, icons, window class behavior)
+- a system-WebView-based runtime model instead of shipping a bundled browser per app
+
+### Key Features
+- **System-WebView Runtime Model:** Generated wrappers stay small because Deskify relies on the system WebView instead of bundling a browser runtime per app.
 - **Automatic Icon Fetching:** Scrapes high-quality 128x128 favicons automatically using the Google Favicon API.
+- **Layered Icon Fallbacks:** Tries site-provided icons first (`<link rel="icon">`, `/favicon.ico`), then falls back to the Google Favicon API, then a dummy icon.
 - **XDG-Compliant System Integration:** Safely creates `.desktop` entries in `~/.local/share/applications` and manages application icons in `~/.local/share/icons/hicolor/`.
 - **Wayland/X11 Ready:** Perfectly binds `StartupWMClass` to ensure your DE groups the app exactly to its custom icon (no generic gear icons in GNOME/KDE taskbars).
 - **Kiosk / Fullscreen Mode:** Pin applications perfectly as dashboards.
@@ -115,11 +212,20 @@ Once the build finishes, `ChatGPT` will instantly appear in your system Applicat
 
 `deskify` derives a safe internal ID from the app name (for example, `ChatGPT` becomes `chatgpt`).
 
+### Backend Modes (`--backend`)
+
+Deskify supports two backend modes:
+
+- `tauri` (default): Uses the system WebView (`webkit2gtk` on Linux). Produces small wrappers and strong Linux desktop integration, but some sites may fail due to engine compatibility.
+- `chromium`: Uses an already installed Chromium-based browser (`chromium`, `google-chrome`, `brave`, etc.) in app mode. Better site compatibility and no local Tauri build, but depends on a browser installed on the system.
+
+If a site does not work in the default `tauri` backend, try `--backend chromium`.
+
 #### Advanced Build Options
 ```bash
 deskify build \
-  --url "https://netflix.com" \
+  --url "https://example.com/dashboard" \
-  --name "Netflix" \
+  --name "Dashboard" \
   --fullscreen \
   --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 Safari/537.36" \
   --dark-mode \
@@ -127,11 +233,71 @@ deskify build \
   --height 720
 ```
 
+Frameless example (without fullscreen):
+
+```bash
+deskify build \
+  --url "https://chat.com" \
+  --name "Chat" \
+  --no-decorations \
+  --width 1200 \
+  --height 800
+```
+
+Preview the generated Tauri config without building/installing:
+
+```bash
+deskify build --url "https://chat.com" --name "Chat" --print-config
+```
+
+Chromium compatibility mode (no local Tauri build):
+
+```bash
+deskify build --url "https://mail.proton.me" --name "Proton Mail" --backend chromium
+```
+
+Chromium with shared browser profile (uses existing browser profile/session model):
+
+```bash
+deskify build \
+  --url "https://app.slack.com" \
+  --name "Slack" \
+  --backend chromium \
+  --profile-scope shared
+```
+
+Chromium with explicit browser binary:
+
+```bash
+deskify build \
+  --url "https://github.com" \
+  --name "GitHub" \
+  --backend chromium \
+  --browser-bin /usr/bin/brave-browser
+```
+
+Preview planned actions only (dry run):
+
+```bash
+deskify build --url "https://chat.com" --name "Chat" --dry-run
+```
+
 * `--icon <PATH>`: Provide a custom PNG icon instead of auto-downloading one.
 * `--fullscreen`: Starts the app in Kiosk mode.
+* `--no-decorations`: Disables native window decorations (frameless window; useful for dashboards/kiosk setups).
 * `--user-agent <UA>`: Useful to bypass webview restrictions on certain platforms.
 * `--dark-mode`: Forces the Tauri webview into a dark theme.
 * `--width <PX>` / `--height <PX>`: Sets the startup resolution.
+* `--backend <tauri|chromium>`: Choose system WebView (`tauri`) or Chromium app mode (`chromium`).
+* `--browser-bin <PATH>`: Use a specific Chromium-based browser binary (Chromium backend only).
+* `--profile-scope <isolated|shared>`: Chromium backend profile behavior (`isolated` creates a per-app profile under `~/.local/share/deskify/profiles/`).
+* `--print-config`: Prints the generated `tauri.conf.json` and exits.
+* `--dry-run`: Shows planned actions without building/installing.
+
+Note for Chromium backend:
+
+- `--no-decorations` is best-effort and may be ignored by the browser/window manager.
+- `--width` and `--height` are applied together (`--window-size`) only when both are provided.
 
 ### Managing Apps (`list` & `remove`)
 You can view all applications generated by `deskify`:
@@ -139,10 +305,11 @@ You can view all applications generated by `deskify`:
 deskify list
 ```
 *Output:*
+
 ```text
 Installed Deskify Apps:
 - ChatGPT (Internal ID: chatgpt)
-- Netflix (Internal ID: netflix)
+- Home Assistant (Internal ID: home-assistant)
 ```
 
 To entirely uninstall an app (including the binary, desktop entry, and icons):
@@ -152,6 +319,34 @@ deskify remove chatgpt
 
 `remove` expects this **internal ID** (sanitized lowercase letters, numbers, `-`), not the display name.
 
+### Updating Apps (`update`)
+
+Rebuild and reinstall an existing app ID without manually running `remove` + `build`:
+
+```bash
+deskify update chat --url "https://chat.com" --name "Chat" --no-decorations
+```
+
+Alpha note: `update` currently requires `--url` because Deskify does not persist app URLs/config metadata yet.
+`update <id>` keeps the existing internal ID stable even if you change the display name.
+
+You can also preview an update:
+
+```bash
+deskify update chat --url "https://chat.com" --dry-run
+deskify update chat --url "https://chat.com" --print-config
+```
+
+### Diagnostics (`doctor`)
+
+Check local prerequisites and common environment issues (Rust/Cargo, `cargo tauri`, `pkg-config`, directories):
+
+```bash
+deskify doctor
+```
+
+`doctor` also checks whether a Chromium-based browser is available in `PATH` for `--backend chromium`.
+
 ---
 
 ## 🧪 Manual Smoke Test Checklist (Before a Public Release)
@@ -179,7 +374,7 @@ Expected: clean validation error and no unintended file deletion.
 - Start with **source-first** releases (repository + tags)
 - Add automated binary releases later via GitHub Actions
 
-For the first public launch, tagging `v0.1.0-alpha.1` is a sensible default.
+For the current public alpha, use `v0.1.0-alpha.2` (and continue with `v0.1.0-alpha.N` for follow-up releases).
 
 ---
 

docs/github-labels.json

@@ -0,0 +1,72 @@
+[
+  {
+    "name": "architecture/runtime",
+    "color": "5319E7",
+    "description": "Runtime model, shared runtime, config-based apps, install model evolution"
+  },
+  {
+    "name": "distro-compat",
+    "color": "D93F0B",
+    "description": "Distro-specific build/runtime issues and environment differences"
+  },
+  {
+    "name": "integration",
+    "color": "0E8A16",
+    "description": "Desktop integration topics (.desktop, icons, launchers, window class behavior)"
+  },
+  {
+    "name": "icons",
+    "color": "FBCA04",
+    "description": "Favicon fetching, icon parsing, icon quality, and fallback behavior"
+  },
+  {
+    "name": "good first issue",
+    "color": "7057FF",
+    "description": "Scoped tasks suitable for first-time contributors"
+  },
+  {
+    "name": "needs testing",
+    "color": "BFDADC",
+    "description": "Behavior change needs manual or wider validation across systems"
+  },
+  {
+    "name": "design decision",
+    "color": "1D76DB",
+    "description": "Affects long-term architecture or product direction"
+  },
+  {
+    "name": "docs",
+    "color": "0075CA",
+    "description": "README, CONTRIBUTING, examples, troubleshooting, and release notes"
+  },
+  {
+    "name": "bug",
+    "color": "D73A4A",
+    "description": "Incorrect behavior or regression"
+  },
+  {
+    "name": "enhancement",
+    "color": "A2EEEF",
+    "description": "Feature or improvement request"
+  },
+  {
+    "name": "ci",
+    "color": "C5DEF5",
+    "description": "GitHub Actions, release workflows, and build checks"
+  },
+  {
+    "name": "feature",
+    "color": "84B6EB",
+    "description": "User-facing functionality addition (release note category)"
+  },
+  {
+    "name": "fix",
+    "color": "E99695",
+    "description": "Behavior correction or bug fix (release note category)"
+  },
+  {
+    "name": "chore",
+    "color": "FEF2C0",
+    "description": "Maintenance tasks and non-user-facing housekeeping"
+  }
+]

docs/maintainer-notes.md

@@ -0,0 +1,46 @@
+# Maintainer Notes
+
+This document captures lightweight repo-management conventions for `deskify` during the alpha/MVP phase.
+
+## Issue Labels (Recommended)
+
+Use labels to make project direction visible and to reduce triage friction.
+
+- `architecture/runtime` - runtime model, shared runtime, config-based apps, install model evolution
+- `distro-compat` - distro-specific build/runtime issues (WebKitGTK, packaging prerequisites, environment differences)
+- `integration` - desktop integration topics (`.desktop`, icons, launchers, window class behavior)
+- `icons` - favicon fetching, icon parsing, icon quality/fallback behavior
+- `good first issue` - scoped tasks suitable for first-time contributors
+- `needs testing` - behavior change needs manual or wider validation across systems
+- `design decision` - issue/PR affects long-term architecture or product direction
+- `docs` - README, CONTRIBUTING, examples, troubleshooting, release notes
+- `bug` - incorrect behavior or regression
+- `enhancement` - feature or improvement request
+- `ci` - GitHub Actions, release workflows, build checks
+
+Label definitions for GitHub setup are stored in `docs/github-labels.json`.
+If you use GitHub CLI, `scripts/setup-github-labels.sh <owner/repo>` will create/update them.
+
+## Triage Heuristics (Alpha)
+
+- Prefer labeling directionally first (`architecture/runtime`, `distro-compat`, `integration`) before priority.
+- Use `design decision` early when a discussion can create long-term constraints.
+- Add `needs testing` to changes that touch build/install/remove flows or desktop integration behavior.
+- Distinguish user-environment issues from code bugs (`distro-compat` + details) to avoid misclassifying support reports.
+
+## Release Notes Categories (Suggested Mapping)
+
+- `feature`, `enhancement` -> user-facing functionality additions
+- `fix`, `bug` -> behavior corrections and regressions
+- `docs` -> documentation changes
+- `chore`, `ci` -> maintenance and pipeline work
+
+## Maintainer Framing (README / Issues)
+
+During alpha, consistently frame Deskify as:
+
+- a Linux-first web app integration tool
+- an early MVP with intentional per-app build architecture
+- a project with a visible evolution path toward runtime/config-based installs
+
+This helps avoid "Nativefier clone" framing as the default community label.

scripts/setup-github-labels.sh

@@ -0,0 +1,43 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v gh >/dev/null 2>&1; then
+  echo "Error: GitHub CLI ('gh') is not installed." >&2
+  exit 1
+fi
+
+repo="${1:-}"
+labels_file="${2:-docs/github-labels.json}"
+
+if [[ -z "${repo}" ]]; then
+  echo "Usage: $0 <owner/repo> [labels-json-path]" >&2
+  echo "Example: $0 spalencsar/deskify" >&2
+  exit 1
+fi
+
+if [[ ! -f "${labels_file}" ]]; then
+  echo "Error: labels file not found: ${labels_file}" >&2
+  exit 1
+fi
+
+if ! command -v jq >/dev/null 2>&1; then
+  echo "Error: 'jq' is required to read ${labels_file}." >&2
+  exit 1
+fi
+
+echo "Syncing labels to ${repo} using ${labels_file} ..."
+
+jq -c '.[]' "${labels_file}" | while IFS= read -r label; do
+  name="$(jq -r '.name' <<<"${label}")"
+  color="$(jq -r '.color' <<<"${label}")"
+  description="$(jq -r '.description' <<<"${label}")"
+
+  if gh label edit "${name}" --repo "${repo}" --color "${color}" --description "${description}" >/dev/null 2>&1; then
+    echo "Updated: ${name}"
+  else
+    gh label create "${name}" --repo "${repo}" --color "${color}" --description "${description}" >/dev/null
+    echo "Created: ${name}"
+  fi
+done
+
+echo "Done."