persona: strengthen + duplicate the female-gender rule in Russian ...

The English one-liner was losing to the models' masculine default
(position at prompt head + weak signal). Now: a strict Russian rule
right after the intro and a short self-reminder at the very end of
persona.txt; same strengthening + reminder in persona_navi_code.txt.

swarm names: single female name (user preference; collisions fixed by hand)

swarm names: two female names (Japanese/American/Spanish) instead of adjective-animal ...

Single names would collide across a swarm (peers are addressed by name),
a mixed pair like 'yuki-grace' or 'sofia-rin' gives 150x150 combinations.
Only affects NEW installs - existing instance.json names stay as they are.

swarm stage 2: peer-to-peer channel — /peer endpoints + peer tool ...

Server side (navi/api/routes/peer.py, port 8099):
- GET /peer/hello — open discovery ping (name, uuid prefix, version)
- GET /peer/status — PSK; identity, uptime, machine facts, hive view
- POST /peer/ask — PSK; one-shot agent run under PEER_ASK_PROFILE
  (default server_admin) answers, one concurrent ask at a time
- loop guard: answering agent runs without the peer tool (deterministic
  recursion cut) + own-uuid asks refused with 409
- verify_swarm_key in navi/swarm.py accepts .swarm-key.previous
  (rotation window, constant-time)

Client side (navi/tools/peer.py):
- peer tool: list (hive book, stale cache fallback marked), status,
  ask by swarm name; asks go direct peer-to-peer, hive never on the
  message path
- audit events on both sides (peer.ask_sent/received/answered/failed)

peer tool added to server_admin, navi_code, developer profiles.

swarm stage 1: instance identity, PSK, hive registry, announce loop ...

- navi/identity.py: adjective-animal names + uuid in instance.json
  (generated at install, renameable by hand)
- navi/swarm.py: HiveAnnouncer - periodic POST /announce to the hive
  with non-blocking reachability tracking (transitional logs, /health
  export, hive_status context provider reports outages to the agent)
- hive/: standalone FastAPI address book (SQLite, port 8087, PSK via
  X-Swarm-Key with .swarm-key.previous rotation window, TTL online
  status, host from client IP, port from payload). Not installed or
  started by default - run manually on the main server.
- ports moved to 8099 (API) / 8098 (UI MCP)
- install.sh: PYTHONIOENCODING=utf-8 in the systemd unit, generates
  instance.json and .swarm-key on fresh installs

manuals: replace a live SSH credential in the spawn_agent example with placeholders ...

The full example carried a real host/user/password combination. Examples
must use fictional values; the leaked password should be rotated on the
host (git history still contains the old string).

port: 8000/8001 -> 8099/8098 everywhere ...

navi runs on shared servers where 8000/8001 are usually taken. New
defaults: API 8099, navi_ui MCP 8098. Touched: config defaults
(navi_port, navi_ui_mcp_port, public_url, gnauth_redirect_uri),
navi-server launcher docs, env.template/.env.example, install.sh
health-check fallback, terminal client base_url, webclient dev configs
(useWebSocket, contentLinks, vite proxy), android url hint, docs.
Also made the navi_ui FastMCP constructor port settings-driven instead
of a hardcoded 8001 (it was overridden at start anyway).

fix: ASCII-safe startup log messages + force UTF-8 stdout in the systemd unit ...

A unit on an old distro without a UTF-8 locale gets latin-1/ascii
stdout; structlog's print of the em-dash in the webclient-disabled
message raised UnicodeEncodeError and killed the app at startup
(Application startup failed, crash-loop restart counter 28). The unit
now sets PYTHONIOENCODING=utf-8 so any future non-ASCII log line is
safe too.

fix: declare rich and python-dateutil — imported directly by the TUI and time_parser ...

Same masking pattern as pillow: the fat dev venv had both (rich via
textual, dateutil via matplotlib), fresh installs did not. dateutil is
a guarded lazy import so it only degraded time parsing silently; rich
is imported unguarded across clients/terminal/.

fix: declare pillow — PIL is imported directly (agent.py, image_view.py) ...

Pillow reached local dev venvs transitively via unrelated dev packages
(CairoSVG, matplotlib, reportlab), masking a missing direct dependency.
On a fresh install the server crashed at import: ModuleNotFoundError:
No module named 'PIL'.

fix: require gnexus-gauth under its real distribution name ...

pip (recent versions) validates that a direct-reference dependency name
matches the built distribution metadata. The gnexus-auth-client-py repo
produces a distribution named gnexus-gauth (import: gnexus_gauth), so
declaring it as gnexus-auth-client-py made pip discard the source and
fail install on the deployment server. The URL is unchanged; only the
requirement name now matches the metadata.

deploy: auto-install docker compose v2 plugin when the host lacks it ...

Ubuntu 18.04's docker packages predate compose v2. The plugin is a
single static binary that runs on any distro with docker CLI >= 18.09,
so the script downloads it into /usr/local/lib/docker/cli-plugins
(system-wide — sudo docker compose sees it too) when docker compose is
unavailable, with the same offline pattern as the python tarball: a
pre-downloaded binary next to install.sh wins. If the CLI is too old
to support plugins at all, the error asks for docker --version.

deploy: standalone CPython fallback for old distros ...

venv cannot be shipped in the repo — it embeds absolute paths and
distro-specific compiled wheels (asyncpg, uvloop, cryptography), so it
dies on any other machine. Instead, when the host has no python >= 3.11
(Ubuntu 18.04: 3.6, 22.04: 3.10; system python must not be replaced),
install.sh fetches a standalone astral python-build-standalone CPython
3.12 into .python/ — self-contained, needs only glibc >= 2.17, works
on any distro. The tarball is cached next to the repo and reused; on
offline servers a pre-downloaded tarball next to install.sh wins.
Verified locally: tarball layout, venv creation, pip install.

deploy: pick the newest python >= 3.11 instead of hardcoding python3 ...

Ubuntu 22.04's system python3 is 3.10 and must not be replaced (apt
depends on it) — a deadsnakes install lives under python3.11/3.12.
The install now tries those names before plain python3 and builds
the venv with whichever qualifies, with a hint in the error path.

deploy: README opens with the full install breakdown

deploy: regenerate placeholder secrets from the deploy branch's .env on first install

deploy: one-command server bundle (dockerized postgres + systemd) ...

deploy/install.sh — everything in one command: prerequisite checks,
.env provisioning from env.template (generated DB password), dockerized
PostgreSQL (pgvector image, restart: always, bound to 127.0.0.1, vector
+ pg_trgm extensions), venv + pip install, a systemd unit with
Restart=always (the server lives from installation, per the roadmap
where these modules become each other's subagents), health check, and
navi-code/navi-server symlinks into PATH. Idempotent — safe to re-run.

Default deployed shape: web UI off, auth off, terminal client only.
Re-enabling the web panel later is editing .env + restart — nothing is
removed from the tree.

The deploy branch (next commit set) differs from master only by a
filled-in .env.

server: NAVI_WEBCLIENT_ENABLED gate + navi-server launcher ...

NAVI_WEBCLIENT_ENABLED=false removes every web-facing route (/, /assets,
/images, /content-viewers, /content, /admin panel, /debug*) and skips
the navi_ui MCP server — its only consumer is the webclient. The REST
API and WS the terminal client uses stay fully intact, and so does the
/admin/* JSON API (still gated by require_admin). Static mounts use
check_dir=False so a tree without webclient/dist imports fine.

New navi-server console script (navi/server.py): uvicorn launcher that
reads NAVI_HOST/NAVI_PORT from settings — the systemd unit needs no
hardcoded values.

Default stays true (full web UI), so nothing changes for dev setups;
subprocess route tests cover both modes.

mcp: a dead MCP endpoint no longer kills server startup ...

A failed transport connect inside the MCP SDK's anyio cancel scopes
surfaces as CancelledError without any task.cancel(). The runner mistook
that for a real teardown, cancelled the in-flight caller's future, and
McpManager.load_all (which only catches Exception) let it blow up the
whole lifespan startup — one unreachable server in mcp_servers.d/ meant
a dead Navi.

The runner now distinguishes real task cancellation
(asyncio.current_task().cancelling()) from the anyio artifact: the
latter is surfaced to the caller as a normal connect failure, the
server pool marks it disconnected and the health-check loop retries.
Also, when the runner dies for any reason, pending queue commands are
failed instead of leaving _send callers hanging forever.

docs: sync with the plan rework and compression pipeline ...

- planning: plan tool flow (agent-invoked, no pre-turn gate), confirmation
  by COMPLEXITY, think=False + 20k-char Phase 1 window, retired flags
  removed from profiles/api docs
- compression: all four triggers through compress_and_save_session,
  real-baseline gates, head+tail summary input, _plan_compression shared
  decision, actual config defaults (0.90 threshold, 6000 summary tokens,
  32k input cap)

compress: route every trigger path through compress_and_save_session ...

- CompressionWorker keeps the real-token gate (ctx.context_tokens) but now
  delegates to compress_and_save_session(reason="postturn") — it used to
  call compress_context directly with its own save logic and silently
  no-op'ed on any summarizer failure, leaving the session over the
  threshold until the next turn's gates
- pre-turn and /compact gates use real_baseline_estimate instead of the
  chars//3 heuristic (mid-turn already did), so code-heavy contexts
  compress in time instead of tripping ContextTooLargeError
- summarizer input keeps head + tail instead of head-only truncation,
  which silently dropped the newest summarized messages closest to the
  keep window
- critical tool results over the 4000-char budget keep head+tail halves
  instead of collapsing to the 800-char non-critical preview (a 3999-char
  read survived whole, a 4001-char one lost 98%)
- images count 500 tokens each, not 500 per message carrying them
- _plan_compression is the single partition decision shared by
  compress_context and would_compress, so the dry-run prediction cannot
  drift from the real path; the trigger reason is now logged
  (preturn/midturn/postturn/forced)

profiles: retire gate flags and retrain prompts for the plan tool ...

- drop planning_enabled / planning_mandatory / planning_phase2_enabled /
  observe_skips_plan_enabled / adaptive_replan_enabled from AgentProfile,
  the loader and admin serialization
- add `plan` to native tools of developer, navi_code, tool_developer,
  secretary, server_admin, modeler_3d — without the gate they would
  otherwise lose planning entirely
- system prompts: call plan for non-trivial multi-step work before
  execution; complex plans get presented for confirmation; stuck or goal
  changed -> plan with a reason

planning: replace the mandatory pre-turn gate with an agent-invoked plan tool ...

- Phase 2 (critique) retired; observe/MODE and the top-level DIRECT shortcut
  removed (sub-agents keep DIRECT for trivial subtasks)
- replan merged into plan: `reason` (+ updated_goal) packs the re-plan
  context, without a reason it is fresh planning
- both phases call the LLM with think=False — cloud reasoning models leak
  their chain-of-thought into structured output on non-streaming calls —
  and strip the gemma "thought<channel|>" content artifact
- Phase 1 conversation windowed to ~20k chars, newest-first with the
  original task pinned (28.7k-token prompts came back as 1-token output)
- confirmation by COMPLEXITY: the tool result tells the agent to present
  complex plans and wait; sub-agents keep the execute-now injection
- PlanningStatus/PlanReady reach the UI mid-turn via current_event_sink
  (ctx.event_sink is None in the agent loop — events silently never
  reached the WS before)
- agent gate, casual-message detector and adaptive re-plan nudges removed;
  anti_stall keeps only stall detection

tests: fake_run_agent accepts hidden kwarg (merged navi_ui form_submit path)

webclient: rebuild dist from merged source (navi_ui + XSS fixes); keep dist tracked

Merge branch 'master' into feature/navi-code ...

# Conflicts:
#	navi/api/websocket.py
#	navi/config.py
#	navi/core/agent.py
#	navi/core/orchestrator.py
#	navi/main.py

navi_code: add gemma4 31b/26b qat models to the profile fallback chain

security: critical batch 1 — RCE/XSS/CORS/webhook hardening ...

Backend:
- auth/deps: fix refresh-lock clock race (cleanup now monotonic like the cache)
- core/registry: add missing structlog logger (NameError on fallback path)
- config: GNAUTH_WEBHOOK_SECRET, NAVI_ALLOWED_ORIGINS (+list property)
- webhooks: HMAC-SHA256 signature verification (503 unconfigured in auth mode,
  unsigned+warning in no-auth mode, 403 bad/stale signature, 400 bad JSON)
- main: CORS from NAVI_ALLOWED_ORIGINS in auth mode (fail-fast on empty),
  eval router behind require_admin, /debug only registered in no-auth mode
- auth routes: mobile-done sid validation (32 hex) + CSP header + safe JS
  escaping (reflected XSS); Secure cookie flag via helper (https base URL)
- websocket: anonymous WS rejected in auth mode (closes legacy-session RCE);
  socket registered only after access checks; stop_session auth gate
- messages: REST agent start now takes session lock + busy flag (409 on
  active run), contextvars reset in finally

Webclient:
- useMarkdown: DOMPurify.sanitize on all rendered markdown (stored XSS),
  image-URL scheme whitelist, delegated error listener (no inline onerror)
- html.html artifact viewer: sandbox without allow-same-origin (opaque origin)
- tests: DOMPurify runs under jsdom (happy-dom Node.prototype.nodeName getter
  breaks DOMPurify); useWebSocket tests get localStorage stub + ui-kit alias

Tests: pytest 1049 passed, 1 skipped; vitest 61 passed

navi_code: add web lookup, ssh, and image_view — grow beyond local-only ...

navi_code was strictly local: no web, no remote hosts, no image viewing. That
made it lean on the developer profile whenever a coding task needed a doc
lookup or a remote command. Bring those capabilities in so navi_code covers
full coding work itself, while staying terminal-first and local-by-default.

config: agent gains image_view, ssh_exec, and the navi-web MCP (search/browse/
request); subagent gains image_view + navi-web (no ssh_exec — sub-agents don't
reach remote hosts, matching developer). Description/short_description/
full_description updated to "terminal-first with web and remote access". Also
includes the gemma4:12b-it-qat-128k model in the model list (local 128k-context
option alongside 31b-cloud).

prompt: soften "Local-only, no remote hosts" to "local by default, with web
lookup (docs/APIs) and ssh (remote ops) when the task needs it". Add compact
Web lookup and Remote access sections under Execution environment, and update
the sub-agent toolset briefing to list image_view + web and to exclude ssh_exec.
scope_boundary still applies; ssh destructive/system-wide actions need user
confirmation. Kept additions minimal to avoid bloating the prompt for the 12b
model.

navi_code: stop delegating code work to the developer profile ...

navi_code was systematically spawning sub-agents as `developer` instead of
itself, even though it already covers local code work. Root cause was a
three-channel nudge: the navi_code prompt recommended `developer` for "general
code work" and framed omit (-> navi_code) as the exception; spawn_agent's
description listed `developer` as the coding example and never mentioned
navi_code; the injected Available-profiles list shows developer's broad
"General-purpose software development" blurb. The planner locks profile_id at
plan time on those same signals, so the bias is baked in before execution.

Flip the default in all three places: for code work OMIT profile_id so the
sub-agent runs as the current profile (navi_code); set profile_id only for a
different specialisation (secretary/server_admin/tool_developer). developer is
not removed as a profile — it is just no longer recommended from navi_code.