DevTrack

Never write a standup again.

You commit. Tickets update, EOD reports write themselves — silently, in your voice, entirely on your machine.

devtrack — a single Go binary. Local-first. Offline by default.

The 30-second pitch

You write code. DevTrack handles the rest.

A background daemon watches your commits and infers everything around them — which ticket you're on (from the branch name), what you did today, what the standup should say. It drafts the ticket comment and the EOD report in your writing voice, learned from your own git history. Your only obligation: name branches with ticket IDs.

Nothing is sent behind your back. Every outbound action — a Jira comment, a ticket transition, an email — is staged in a review queue first. You approve it, or you let it earn auto-approve over time. The daemon never prompts you, never blocks a commit, and never interrupts.

And it's the memory your AI agents lack

Available since v3.1.0: Phase 9 onboarding and the local, read-only MCP server ship in the latest public release, v3.1.1. Five native MCPB bundles are available for Windows, macOS, and Linux.

Coding agents are session-based: they exist while invoked, then forget. DevTrack is always on. One command —

devtrack mcp setup

— and Claude Code knows your active ticket, today's commits, your pending queue, and how you write. Nothing else runs at 6pm, groups the day's commits by ticket, and has the EOD ready before you ask.

Trust

Local Ollama by default; SQLite on disk. The default daily path stays on your machine. If you configure a PM system, email/chat delivery, an external server, or a cloud LLM, DevTrack sends only the payload needed for that enabled operation. Anonymous usage telemetry is opt-in and off unless you run devtrack telemetry on.

Related MCP server: devbase

Ten-minute quickstart

The latest public release is v3.1.1. Download the matching platform asset from GitHub Releases, or build from source:

git clone --branch main --single-branch https://github.com/sraj0501/Devtrack_.git
cd Devtrack_/devtrack_client
go build -o devtrack .
sudo install -m 0755 devtrack /usr/local/bin/devtrack

Verify that this is an MCP-capable build, then run setup from the Git repository you want DevTrack to watch. Choose none when asked for a PM integration if you only want to try the local path. Managed mode requires a PostgreSQL URL for the Python service; Ollama remains the default LLM and can finish preparing in the background.

devtrack mcp status           # must report six registered tools
cd /path/to/the/repo/to/watch
devtrack setup

Minute 2: local context, no Python or model required

The Go binary and local SQLite database are ready as soon as setup finishes. Wire the current repository into Claude Code, then exercise the same MCP server locally:

devtrack mcp setup
devtrack mcp test

Reload Claude Code after mcp setup. Its DevTrack tools can now read the active ticket, today's commits, pending actions, voice profile, ticket context, and a template EOD summary. The MCP server runs on demand over stdio; it does not need a background Python process.

Minutes 3–10: start the silent worker

devtrack start
devtrack status
devtrack doctor

status and doctor report background Python, PostgreSQL, and LLM readiness without blocking Git monitoring or MCP. Once the AI server reports ready, create a normal ticket-named branch and commit:

git switch -c feature/AUTH-42-refresh-token
git commit -m "fix auth redirect"

devtrack logs                # confirm the commit and ticket were detected
devtrack queue               # review local pending actions and confidence
devtrack eod                 # generate a narrative; stages it before any delivery

Do not run queue approve while evaluating the no-send path. With the workspace PM integration set to none and no --email argument, the walkthrough uses no PM credentials and has no external destination. For a disposable, recorder-friendly version that verifies actual log output instead of using a canned transcript, see the demo storyboard.

What is ready when?

The Python service and model preparation are background work. If they are not ready by minute ten, keep coding and check devtrack doctor; the Go-native path remains usable and commits are not blocked.

Update an existing installation

devtrack upgrade

devtrack upgrade installs the latest public release, including the Phase 9 onboarding and MCP commands introduced in v3.1.0.

The daemon mines enabled local repositories in Managed mode and builds the voice profile once the local AI server is reachable. devtrack status and devtrack doctor show the persistent result and suggest devtrack work report when the profile is ready.

Setup also checks Ollama's local model inventory. An existing generation model is used immediately without another pull. If no usable local model is ready and an OpenAI or Anthropic key is already in the environment, setup offers that key as a temporary fallback while Ollama downloads; Ollama stays primary and automatically takes over when the local model becomes available.

Updating? Run devtrack upgrade to download and install the latest binary automatically (fetched from GitHub Releases; supports Linux/macOS and Windows). If the binary is in a root-owned location (e.g. /usr/local/bin), run sudo devtrack upgrade instead. On Windows, re-run as Administrator if a permission error occurs. Versioned migrations are applied automatically and the daemon is restarted after a successful upgrade.

devtrack setup writes a complete environment file under the DevTrack XDG data directory and registers it in ~/.devtrack/devtrack.conf. Visible runtime defaults are editable; valid shell, CI, and secret-manager overrides still take precedence.

Full walkthrough and guides: devtrack.cloud

Moving to a new machine?

Project memory and agent logs are committed to the repo (.claude/memory/, Data/agent_logs/). After cloning, wire up Claude Code's memory system with one command:

# Replace <path-key> with the absolute repo path, slashes replaced by hyphens
# e.g. repo at /home/sraj/devtrack → -home-sraj-devtrack
mkdir -p ~/.claude/projects/<path-key>/
ln -s $(pwd)/.claude/memory ~/.claude/projects/<path-key>/memory

Claude Code will then read and write memory directly to the repo, keeping it in sync with git.

The core loop

The daemon is silent. It does not prompt, block, or interrupt — it observes and stages.

You:  git checkout -b feat/AUTH-42-refresh-token
You:  git commit -m "fix auth redirect"
                │
                ▼
        DevTrack observes (background — you are not interrupted)
                │
        ├── infers ticket AUTH-42 from the branch name
        ├── drafts a ticket comment in your voice
        └── STAGES it — nothing is sent yet
                │
                ▼
        devtrack queue        # review what's waiting
        devtrack queue approve <id>
                │
        At 6pm: today's commits, grouped by ticket
                ▼
        devtrack eod          # the standup, already written

Review the queue whenever you like — it waits for you:

devtrack queue                  # what DevTrack wants to send
devtrack queue approve <id>     # send it
devtrack queue reject <id>      # discard it
devtrack eod                    # preview today's EOD report

Optional: AI-enhanced commits

Separately, devtrack git commit is an interactive wrapper that refines your commit message with AI, offers a ticket picker, and can log time. It is opt-in and never part of the silent daemon path:

eval "$(devtrack shell-init)"    # add to ~/.zshrc or ~/.bashrc — done once
devtrack enable-git              # opt this repo in

After that, git commit routes through DevTrack for monitored repos. Everything else (git push, git pull, git status) goes straight to real git, unmodified. Escape hatch: GIT_NO_DEVTRACK=1 git commit -m "skip".

AI commit enhancement is only active when the daemon is running. If you stop it, git commit passes through with zero delay and no errors.

What it connects to

Key features

The pending-actions queue — nothing is sent without review

Every outbound action DevTrack wants to take is staged first, never fired blind. This is the trust primitive: one reviewable queue for everything that would otherwise write to your Jira, GitHub, or inbox.

devtrack queue                   # list pending actions (default)
devtrack queue --all             # include recently posted/rejected
devtrack queue status            # one-line summary: pending / posted today / rejected today
devtrack queue approve <id>      # send it now
devtrack queue reject <id>       # discard — will not post
devtrack queue edit <id> <json>  # fix the payload before it goes

Each action carries a confidence score. As you approve a given action type repeatedly, it can earn auto-approve — so DevTrack gets quieter the more you trust it, not louder.

End-of-day report — the standup, already written

devtrack eod                # generate today's report
devtrack eod show           # print the most recent narrative
devtrack eod status         # is one staged?

Groups the day's commits by ticket and writes the narrative in your voice. It is staged in the queue like anything else — review it, then send.

Multi-repo monitoring

# workspaces.yaml
workspaces:
  - name: work-api
    path: ~/work/api
    pm_platform: azure
    pm_assignee: jane@example.com
    pm_iteration_path: "MyProject\\Sprint 5"
    pm_area_path: "MyProject\\Backend"
  - name: oss-lib
    path: ~/oss/my-lib
    pm_platform: github
    pm_milestone: 3
  # Dual-platform: same repo tracked in GitHub (code) + Azure DevOps (PM)
  - name: my-api-github
    path: ~/work/my-api
    pm_platform: github
    pm_org: acme-corp
    pm_username: sraj0501
    skip_issues: true          # code-only: excluded from devtrack issues + ticket sync
  - name: my-api-ado
    path: ~/work/my-api
    pm_platform: azure
    pm_org: acme-corp
    pm_username: jane@acme.com

Per-workspace PM overrides (pm_assignee, pm_iteration_path, pm_area_path, pm_milestone) are applied when DevTrack creates work items or issues for that repo — Azure uses assigned_to/area_path/iteration_path, GitHub/GitLab use assignees and milestone. Omit any field to use the global default.

skip_issues: true marks a workspace as code-only — it is excluded from devtrack issues, ticket sync, and the commit-time ticket picker. Use this when the same repo is tracked in two PM platforms (e.g. GitHub for code review, Azure DevOps for sprint planning) to prevent duplicate ticket lists.

devtrack workspace list
devtrack workspace add my-project ~/code/project --pm github
devtrack workspace install-hooks   # push post-commit hooks to all enabled workspaces

Empty repositories: If a monitored workspace has no commits yet, the daemon watches the folder silently and begins triggering normally once the first commit arrives — no log spam or errors during the empty-repo period.

Work session tracking

devtrack work start AUTH-42    # start timing a ticket
devtrack work stop             # auto-measures duration
devtrack work report           # EOD narrative in terminal
devtrack work report --email me@org.com

Every git commit while a session is active automatically attaches its hash — no manual logging.

git-sage — local LLM git agent

devtrack sage do "squash my last 5 commits"
devtrack sage ask "how do I rebase onto main?"

Runs an agentic loop: plans operations, executes them, reads output, handles failures with rollback, only asks when genuinely ambiguous. Session approval dialog (auto / review / suggest-only), step history, and interactive undo built in.

Personalized AI ("Talk Like You")

devtrack enable-learning        # opt in
devtrack learning-sync          # mine your git history
devtrack show-profile           # view your inferred writing style
devtrack test-response "Completed auth module"

Learns your writing voice from your own git history — local, automatic, no external service. It combines a style profile with ChromaDB RAG (real examples of how you write) to personalize every commit message, ticket comment, and report the system generates.

On a fresh Managed installation, the daemon automatically seeds Tier 0 voice data from enabled local Git workspaces and generates the first profile in the background. Completion is saved locally in first-run-profile.json; no PM action is sent and daemon startup never waits for the profile.

Microsoft Teams is an optional extra signal (TEAMS_ENABLED), not a requirement — the local git-history path is the default and works entirely offline.

Ticket alerter

devtrack alerts                 # unread notifications (last 24 h)
devtrack alerts --all
devtrack alerts --clear

The Go-native background poller watches GitHub and Azure DevOps for assigned work, comments, review requests, and status changes. It can deliver terminal, OS, Telegram, and Slack-webhook notifications.

• GitHub: Issue/PR assigned, review requested, comment on involved issue

• Azure DevOps: Work item assigned, comment added, state changed The poller is Go-native and runs inside the daemon — no Python subprocess, no MongoDB. Alert state (last_checked per source) and notifications persist to SQLite, so poll continuity survives daemon restarts.

Telegram bot — remote control from your phone

Control the daemon and supervise queued work without opening a terminal:

/status | /logs | /health | /trigger
/pause | /resume | /stop | /restart | /reload
/commits
/queue
/approve <id> | /reject <id> | /edit <id> <json>

See Telegram Bot setup guide for full configuration.

Auto-start at login

One command installs the right service for your OS — no manual plist or unit file editing:

devtrack autostart-install    # macOS → launchd LaunchAgent
                              # Linux/systemd → ~/.config/systemd/user/devtrack.service
                              # WSL without systemd → shell profile block
devtrack autostart-status     # show current auto-start status
devtrack autostart-uninstall  # remove auto-start

Relevant DevTrack runtime variables from the current environment are baked into the service definition at install time so the daemon starts correctly even in a login session without a shell profile. Re-run autostart-install after changing the environment file.

The daemon enforces a single running instance using an OS-level file lock (Data/devtrack.lock). On Windows this is a mandatory lock; on Unix a cooperative flock. Attempting to start a second instance prints a clear error and exits immediately rather than running in parallel and corrupting shared state.

Interactive setup wizard (devtrack setup)

Walks through every required setting interactively and writes the result for you:

devtrack setup

What it does:

• Checks Git is installed before proceeding

• Prompts for operating mode (Managed / External) and LLM provider credentials

• Reuses an installed generation-capable Ollama model without downloading a prescribed model

• When Ollama still needs a model, can retain an already-present OpenAI/Anthropic key as an explicit temporary fallback; key values are never displayed and declining keeps setup local-only

• In Managed mode, starts the optional Python checkout, uv sync, and any needed local Ollama model pull in a detached worker; setup does not wait for them

• Generates the registered XDG environment file with visible runtime defaults and an auto-generated ADMIN_SECRET_KEY

• In Managed mode, writes and validates the required PostgreSQL connection configuration

• Creates the ~/.devtrack/ configuration directory and writes workspaces.yaml there

• Writes WORKSPACES_FILE into the generated environment file, pointing at the workspace file

• Registers shell integration automatically in .bashrc or .zshrc on Unix and the PowerShell profile on Windows

• Writes ~/.devtrack/devtrack.conf pointing at the generated environment file

After devtrack setup completes, run devtrack start — no manual source .env needed. Git monitoring, local SQLite, scheduling, and MCP are ready while the optional AI server finishes in the background. Use devtrack doctor or devtrack status for progress; retry a failed bootstrap with devtrack doctor --repair.

Automatic .env loading

The daemon automatically finds and loads .env at startup. Resolution order:

1. DEVTRACK_ENV_FILE environment variable (explicit path)

2. Path recorded in ~/.devtrack/devtrack.conf (written by devtrack setup)

3. .env file next to the devtrack binary

You no longer need to manually source .env before devtrack start for most setups. The env-first rule still applies for devtrack autostart-install — run it after devtrack setup so the service bakes the correct variables.

Uninstall (devtrack uninstall)

devtrack uninstall             # confirm, then remove DevTrack and its data
devtrack uninstall --keep-data # remove DevTrack but preserve the data directory
devtrack uninstall --yes       # skip the confirmation prompt

The uninstall command asks once for confirmation unless --yes is supplied. It:

• Stops the running daemon (if active)

• Removes the autostart entry (launchd on macOS, systemd on Linux, Task Scheduler on Windows)

• Deletes the configured DevTrack data home, including managed-server files, unless --keep-data is supplied

• Removes the devtrack binary from PATH

The command prints the resolved targets before confirmation. There is no --dry-run flag.

Self-update (devtrack upgrade)

devtrack upgrade          # download and install the latest release binary
sudo devtrack upgrade     # use when the binary is in a root-owned directory (e.g. /usr/local/bin)

What happens on upgrade:

1. Downloads the latest binary for your OS/arch from GitHub Releases (sraj0501/Devtrack_) — Linux/macOS use .tar.gz; Windows uses a direct .exe

2. Applies all versioned migrations that have not yet run (schema changes, config file moves, etc.)

3. Auto-restarts the daemon so the new binary takes effect immediately

4. On Unix: falls back to sudo cp automatically if the target directory is root-owned and the command wasn't run as root

5. On Windows: if a permission error occurs, a message is printed asking you to re-run the command as Administrator

Post-commit hooks for all workspaces

devtrack workspace install-hooks    # install post-commit hook in every enabled workspace

Normally DevTrack installs hooks when the daemon starts. Use this command to push hooks to all workspaces at once — useful after adding new repos to workspaces.yaml.

Webhook + Trigger server (HTTP mode)

The Go daemon spawns backend.webhook_server as a subprocess in the default managed mode. In external/Docker mode the server runs separately and the Go daemon connects to it over HTTPS. Either way the same FastAPI server handles both:

• Inbound webhooks from Azure DevOps, GitHub, GitLab, and Jira at /webhooks/<source>

• Outbound triggers from the Go daemon at /trigger/commit and /trigger/timer

# external/Docker mode only — managed mode starts this automatically
cd devtrack_server && uv run python -m backend.webhook_server

All trigger endpoints require the X-DevTrack-API-Key header (set DEVTRACK_API_KEY in .env). Webhook signature verification uses source-specific secrets (AZURE_WEBHOOK_SECRET, GITHUB_WEBHOOK_SECRET, etc.). GitLab webhooks are registered automatically at startup when GITLAB_WEBHOOK_URL is configured.

The stable request and response shapes, authentication rules, and matching Go/Python contract tests are documented in the HTTP API contract.

Claude Code / MCP Integration (Phase 8)

DevTrack exposes a Model Context Protocol (MCP) server so Claude Code automatically knows your active ticket, commit voice, and pending queue — no manual context-setting needed.

• devtrack mcp — starts the MCP server in stdio mode (the transport Claude Code uses)

• devtrack mcp serve --database PATH — starts it against an explicitly selected devtrack.db (used by packaged MCPB installs)

• devtrack mcp setup — writes .mcp.json in the current directory so Claude Code discovers the server automatically on next launch

• devtrack mcp status — shows the registered tools and server info

• devtrack mcp test — runs an in-process smoke test without starting a full server

• Six SQLite-backed tools: get_active_context, get_today_commits, get_pending_actions, get_voice_profile, get_ticket_context, get_eod_summary. Each declares a title and read-only, non-destructive, idempotent safety annotations.

• The stdio handshake negotiates finalized MCP versions through 2025-11-25, retaining older-client compatibility. The newer 2026-07-28 per-request protocol is not supported yet.

• Reproducible MCPB 0.3 bundles ship for Windows amd64, macOS amd64/arm64, and Linux amd64/arm64. During bundle installation, select the devtrack.db created by devtrack setup. Published bundle hashes are recorded in the release's checksums.txt and official MCP Registry metadata.

• Dockerfile.mcp is the minimal Linux stdio image used for directory build/introspection checks. It creates disposable SQLite state and is separate from devtrack_server/Dockerfile, which runs the optional Python HTTP backend. The root .dockerignore keeps local credentials and runtime data out of that build context.

# One-time setup — run from your repo root
devtrack mcp setup    # writes .mcp.json
# Restart Claude Code — it will connect automatically via stdio
devtrack mcp status   # verify tools are registered
devtrack mcp test     # smoke-test the server in-process

Source: devtrack_client/internal/mcp/ (server core) and devtrack_client/mcp_cmd.go (CLI).

Development-agent playbooks

The repository retains five historical Claude role definitions under .claude/agents/_archive/ and keeps the current role, memory, and authorization contract in .claude/memory/project_local_agents.md. These are project-maintenance assets, not devtrack CLI commands, and the archived files are not advertised as automatically installed Claude slash commands. A contributor's Codex or agent environment may install adapters for the same roles separately.

The documentation-maintenance workflow is checked in at .claude/commands/docu-agent.md; how a contributor invokes it depends on their local agent environment. The planning and engineering roles use Data/agent_logs/project_board.md as their durable contract, while verified implementation history is recorded in Data/agent_logs/engineer_log.md. Role names alone do not authorize commits, pushes, PR operations, releases, publication, or deployment.

Anonymous telemetry — opt-in, off by default

DevTrack sends nothing unless you explicitly opt in:

devtrack telemetry status   # DISABLED by default
devtrack telemetry on       # opt in
devtrack telemetry off      # opt back out at any time

If (and only if) you opt in, the daemon sends an anonymous install/daily-active ping containing a random install UUID, a hashed hardware fingerprint, the event type (install / active), OS, arch, and version. Never code, commit text, diffs, ticket contents, or personal data.

The setting is stored locally and read directly by the daemon, so it works in every operating mode — including lightweight, with no server running.

Admin console (CS-3)

A browser-based admin console built with FastAPI + HTMX. Start it with:

The admin console is server-owned. Run it from devtrack_server/ with uv run python -m backend.admin, or set ADMIN_EMBED=true to mount it on the managed webhook server at /admin. The Go client intentionally has no admin-start command.

Sign in with ADMIN_USERNAME / ADMIN_PASSWORD (set in .env). The dashboard shows live trigger-activity stats (triggers today, commits today, last trigger time, errors in the last 24 h) that refresh every 30 seconds via HTMX without a full page reload.

Pages and capabilities:

Single-process mode (ADMIN_EMBED): By default the admin console runs as a separate process on ADMIN_PORT (default 8090). Set ADMIN_EMBED=true to mount the admin router directly on the main webhook server at /admin — no extra port, no extra process:

# .env
ADMIN_EMBED=true          # mount admin at /admin on the webhook server (port 8089)
# or leave false (default) to run on a dedicated port:
ADMIN_PORT=8090

Required .env keys for the admin console:

ADMIN_USERNAME=admin
ADMIN_PASSWORD=changeme          # plain text (dev) or bcrypt hash ($2b$...)
ADMIN_SECRET_KEY=<random-string> # JWT signing key — generate with: openssl rand -hex 32
ADMIN_PORT=8090                  # ignored when ADMIN_EMBED=true
ADMIN_EMBED=false

Runtime visibility

devtrack status            # daemon, capabilities, and managed-bootstrap progress
devtrack doctor            # configuration and dependency diagnosis
devtrack doctor --repair   # retry a failed managed-server bootstrap
devtrack tui               # full-screen client dashboard
devtrack logs -f           # follow daemon logs

The Python server TUI remains available to server operators with cd devtrack_server && uv run python -m backend.server_tui; it is not a Go-client command. Its trigger-throughput pane reads the Go daemon's internal stats endpoint when PostgreSQL mode is active and degrades to zero-valued stats when that endpoint is unavailable.

The daemon health subsystem checks these monitored services:

The last-known port list is persisted so runtime diagnostics can report conflicts across restarts.

Deployment modes

devtrack setup prompts for Managed or External mode on first run and writes the choice to the generated environment file. lightweight remains a supported manual configuration value: it maps to the same internal non-managed mode as external, so the daemon does not spawn Python. Go-native features continue; server-backed calls use the configured (or loopback fallback) URL and degrade if no backend is reachable.

DevTrack runs natively — a Go binary plus a uv-managed Python server. The Go client keeps its offline source of truth in local SQLite and does not connect to a database server. PostgreSQL is mandatory for Python-server persistence and server-side events; MongoDB remains optional as a Teams voice-learning source. Server startup validates PostgreSQL and advances the Alembic schema before accepting traffic; there is no server-side SQLite fallback.

Python AI server

Managed mode (default): devtrack setup configures the deterministic server location and starts a background sparse checkout into ~/.local/share/devtrack/server/, followed by uv sync and, for the local Ollama provider only, a model pull when no usable generation model is already installed. An opted-in cloud-key fast lane remains a fallback behind Ollama, so local inference takes over as soon as the model is ready. The wizard does not wait for these steps; devtrack doctor shows durable progress and failures. No manual dependency setup is needed.

External mode (server on a separate host): clone the repo on that host, cd devtrack_server && uv sync && uv run python -m backend.webhook_server. Set DEVTRACK_SERVER_URL on the client machine.

See docs/INSTALLATION.md for the full setup walkthrough.

Technology

Documentation

Full user guides live on the project website: devtrack.cloud.

Key references in this repo:

Releasing

The canonical release pipeline is .github/workflows/release.yml. It runs when an authorized maintainer pushes a semantic-version tag:

GIT_NO_DEVTRACK=1 git tag -a vX.Y.Z -m "Release vX.Y.Z"
GIT_NO_DEVTRACK=1 git push origin vX.Y.Z

GitHub Actions runs the Go tests, cross-compiles Linux amd64/arm64, macOS amd64/arm64, and Windows amd64, validates the generated MCPB manifests, then publishes the platform binaries/tarballs and five matching .mcpb bundles. It also publishes SHA-256 checksums, server.json, and the official MCP Registry record through GitHub OIDC. v3.1.0 is the first release produced by this complete path. Update release-facing website copy in the same release change.

The older scripts/release.ps1 helper is retained for local maintainer workflows, but it is not the source of truth for published asset names or CI behavior.

Testing

cd devtrack_client && go test ./...                     # Go client suite
cd devtrack_client && go vet ./...                      # lint

cd devtrack_server && uv sync                           # uv manages the venv — never pip
cd devtrack_server && uv run pytest backend/tests/      # Python server suite
cd devtrack_server && uv run pytest backend/tests/ -k <name>   # filter by name

Python business logic must use backend.config typed accessors rather than adding direct environment reads. Missing required variables produce a ConfigError with the variable name rather than a silent None.

Privacy

The default Go + SQLite + Ollama path is local and works without internet. Configured external services receive the minimum context required for the operation you enabled.

• Cloud LLMs are optional. OpenAI/Anthropic/Groq are used only if configured. The prompt may include commit messages, diff context, or work text required by the feature being invoked; do not enable a cloud provider if that conflicts with project policy.

• Nothing is posted without review. All outbound actions are staged in the pending-actions queue until you approve them.

• Telemetry is opt-in and off by default (devtrack telemetry status). No pings are sent unless you run devtrack telemetry on.

• Voice learning is local in managed mode by default. Git-history seeding is local; Teams and external-server learning sources require explicit configuration. Learning data can be wiped with devtrack learning-reset.

License

DevTrack Community License — free for personal use and teams up to 10 users. Enterprise (11+ users) requires a paid license.

devtrack terms          # read the terms
devtrack terms --accept # accept non-interactively (e.g. in CI)

Full text: TERMS.md