## Describe your changes
[#7009](https://github.com/netbirdio/netbird/pull/7009) wrote down what
we expect
from a contribution: an agreed ticket first, a change the author has
run, one
purpose per PR, small enough to review, a title tag CI already enforces.
That
works for contributors who read CONTRIBUTING.md.
A growing share of what reaches the queue is drafted by a coding agent,
and those
tools never read it. The result is predictable and repetitive: a PR with
no ticket
behind it, an approach we would have talked the author out of in five
minutes, a
diff too large to review carefully against a daemon that runs as root, a
description longer than the code it describes, and an author who cannot
answer
questions about their own change. That is not a tooling problem. It is
what
happens when a capable tool is pointed at a repository whose
expectations nobody
told it.
AGENTS.md states those expectations in the format agents pick up
automatically.
The first entry in its stop-and-ask list is asking the contributor for
the
discussion or issue before drafting anything, which is where most of
these PRs
go wrong. It also carries the repository map, the Go conventions we
apply in
review, the local verification commands, the PR template and title-tag
rules,
and instructions to read the review bots rather than resolve their
threads.
CONTRIBUTING.md gains a short section saying plainly that we have no
policy for
or against agents, that this guide exists because of what we keep seeing
rather
than as a restriction on tools, and that whatever produced a diff its
author owns
it. It also records that we weigh whether a contribution is worth
maintaining,
and that what gets merged has to match our security and design
expectations.
CLAUDE.md is a one-line pointer rather than a symlink, deliberately. A
symlink is
tidier, but a Windows checkout without symlink support materialises it
as a plain
file containing the target path, and an agent then reads one word as its
entire
instruction set with no error to show for it. Given how much Windows
work this
repository sees, a pointer file that survives every checkout is worth
the extra
file.
Nothing here is enforced by CI, and no workflow changes. It is guidance,
aimed at
PRs arriving in a reviewable state more often.
## Describe your changes
We are updating the contributing guide to require an issue to be opened
before PRs; this will allow discussing changes before code is shipped.
Update the rest of the file because of outdated information and align
the pull request template
## Issue ticket number and link
- **Wails v3 application** (`client/ui`) with a React + TypeScript + Tailwind frontend replacing the Fyne UI: main connection view, exit-node switcher, networks/peers browser with detail panels, profile management, settings (general, network, SSH, security, troubleshooting, appearance), debug-bundle creation, and a first-run welcome flow.
- **Internationalization**: go-i18n bundle with 9 locales (en, de, es, fr, hu, it, pt, ru, zh-CN) shared between the tray and the frontend.
- **New system tray** implementation with per-platform theme-aware icons, including a native XEmbed host for Linux (`xembed_tray_linux.c`) and a Linux theme watcher.
- **Session handling**: auth session watcher (`client/internal/auth/sessionwatch`), pending login flow, session-expiration dialog and tray notifications, and `netbird login` improvements.
- **Daemon API extensions** (`daemon.proto`): status stream subscription, event stream, networks/exit-node selection endpoints, and richer full status — with probe throttling on the daemon side to protect against UI-driven request storms.
- **UI preferences store** persisted per profile, autostart management via the daemon (single source of truth in HKCU on Windows).
- **Build system**: Taskfile-based builds per platform (macOS, Linux, Windows), Docker cross-compilation images, MSIX/NSIS/nfpm/AppImage packaging, and a new `frontend-ui` CI workflow.
Co-authored-by: Zoltan Papp <zoltan.pmail@gmail.com>
Co-authored-by: Eduard Gert <kontakt@eduardgert.de>
Co-authored-by: braginini <bangvalo@gmail.com>
Co-authored-by: Pascal Fischer <32096965+pascal-fischer@users.noreply.github.com>
Co-authored-by: riccardom <riccardomanfrin@gmail.com>
* Add local lint setup with pre-push hook to catch issues early
Developers can now catch lint issues before pushing, reducing CI failures
and iteration time. The setup uses golangci-lint locally with the same
configuration as CI.
Setup:
- Run `make setup-hooks` once after cloning
- Pre-push hook automatically lints changed files (~90s)
- Use `make lint` to manually check changed files
- Use `make lint-all` to run full CI-equivalent lint
The Makefile auto-installs golangci-lint to ./bin/ using go install to
match the Go version in go.mod, avoiding version compatibility issues.
---------
Co-authored-by: mlsmaycon <mlsmaycon@gmail.com>
* Adds management, signal, and relay (STUN/TURN) health probes to the status command.
* Adds a reason when the management or signal connections are disconnected.
* Adds last wireguard handshake and received/sent bytes per peer
By copying the emulator driver next to our binary, our GUI setting popup works on remote desktop connections
the dll is added as part of our sign pipelines workflow
* Change SetShellVarContext scope to create program links for standard users
* Include guidelines for building the Windows Netbird installer during development
* Add Wireguard driver requirement to Windows build instructions
