Docs

AxiOwl

AxiOwl is a native Rust and Slint desktop application for routing messages between named chats and agents across supported provider surfaces. It exists to provide one clear operator-facing message path instead of a pile of disconnected local chat tools.

This Docs page is based on the main project README and serves as the public-facing technical overview for the current AxiOwl stack.

Current State

• Native Rust application
• Slint frontend shell
• Windows-first desktop setup
• Separate planning and implementation docs kept in the repo

Repository Structure

• src/ for Rust application code
• ui/ for Slint UI definitions
• IMPLEMENTATION_PLAN.md for the project implementation plan
• DETAILED_SLINT_IMPLEMENTATION_PLAN.md for file-by-file architecture and packaging planning
• TASK_CHECKLIST.md for execution tracking
• NAMING_POLICY.md for naming and legacy-string policy

Local Build Policy

The only authoritative local build command is the repo build script:

.scriptsbuild.ps1

That script is the source of truth for building AxiOwl. It performs the current expected build pipeline and should be treated as the live authority instead of older notes, chat logs, or historical plan files.

• Builds the Windows installer-profile executable
• Regenerates the WiX install manifest from that executable
• Builds the MSI from that executable and manifest
• Builds the Linux ARM64 CLI from a real no-space build root using bundled Zig

The MSI output path is:

targetwixaxiowl-0.2.0-x86_64.msi

The build script fails loudly when required invariants fail. A successful installer exit code by itself is not enough proof of a real deployment; installed binaries and live runtime state still need verification.

Install Contract

The MSI is the install path. There is no separate install wrapper, hidden headless path, or alternate deployment contract. Shutdown, file replacement, PATH repair, bundled tooling, startup launch, and activation verification belong inside the installer behavior.

Command Availability

Agent-to-agent AxiOwl tests should not depend on stale helper paths. The installer and startup repair path are responsible for making the installed command available from PATH:

axiowl

On Windows, that normally resolves to the installer-owned shim under the AxiOwl install directory. Legacy shims in older locations are compatibility leftovers, not the source of truth.

Sending Messages

The normal agent-facing command for sending content is:

axiowl send_message --to "<agent name>" --body "<message>"

For multiline content, exact formatting, code, JSON, or anything that should not be cut off, use stdin instead of forcing everything into one shell string:

@'
<full message>
'@ | axiowl send_message --to "<agent name>" --stdin

The current send_message contract is send-only. Programmatic send receipts still exist, but they prove AxiOwl accepted the message and started delivery, not that the recipient later replied.

For machine-readable confirmation:

axiowl send_message --to "<agent name>" --body "<message>" --json

The JSON receipt includes fields such as fast_receipt.original_message_id, derived_status.status, and send_status_summary.status.

Target Architecture

axiowl send_message ... -> local AxiOwl daemon on 127.0.0.1:37631 -> daemon commits message -> daemon starts live delivery -> CLI prints fast receipt

If the local daemon is unavailable, ordinary send_message should fail loudly rather than silently taking some other hidden provider path.

Agent-Facing Options

• --to, --target, or --target-agent
• --thread-id or --target-thread-id
• --body, --message, or --text
• --body-file <path>
• --stdin

Historical or harness-only flags are not part of the normal receiver contract. Receiving agents should only need a target and message content.

Support Commands

axiowl --cam-list-agents
axiowl --cam-list-active-agents
axiowl --cam-list-active-chats
axiowl --cam-message-status
axiowl --cam-vscode-bridge-status
axiowl --cam-vscode-bridge-install --dry-run
axiowl --cam-vscode-bridge-send --operation start_copilot_cli_session --body "<message>"
axiowl --cam-discover

List commands are enrollment-only. They are meant to expose sendable, enrolled targets, not every discovered candidate on a machine.

Startup and Provider Installation

The startup repair path is provider-aware. Codex installs or repairs the AxiOwl skill, VS Code Copilot installs or repairs the bundled bridge extension, and all providers write or refresh generic AxiOwl documentation under the local AxiOwl docs directory.

Startup also writes a provider installation report and the current local guidance files so that the installed command contract stays visible and consistent.

Documentation Notes

This page is a public docs summary derived from the live repository README. Deeper implementation notes, detailed plans, and internal evidence files still live in the repo and should be treated as engineering references rather than public quickstart material.