bin/ww) routes every command to a service script in services/<category>/. The browser UI is a service. The heuristic compiler is a service. Profile management is a service. Even the weapons are discovered and dispatched as services.
This architecture wasn’t a design decision made upfront. It emerged from the requirement that the system be extensible — that adding a new capability shouldn’t require touching core files.
bin/ww is 709 lines. It’s the single entry point for every command. Its job is to:
The discovery mechanism: scan services/ for executables matching the command name. Profile-level services at profiles/<name>/services/<category>/ are checked first — they shadow global services. If no service is found, print an error and exit 1.
This means adding a service is a file operation, not a code change. The dispatcher doesn’t have an explicit registry of known services. It discovers them from the filesystem.
Every service must:
--help / -h with a one-line description and usage examplelib/logging.sh, not raw echoThe help output is the documentation. ww help shows all discovered services with their one-line descriptions, pulled from --help output at startup. A service that doesn’t implement --help is invisible to the help system.
Exit codes matter for the browser UI. A POST /cmd request checks the exit code. Exit 1 means the user made an error — show the error message. Exit 2 means a system problem — show a different error and don’t retry automatically.
services/browser/ is the most complex service. It starts a Python HTTP server, manages its process, and shuts it down. It’s also the only service that runs persistently — every other service runs, completes, and exits. The browser service starts a background process and returns immediately.
That asymmetry is handled by the service contract: ww browser returns 0 if the server started successfully. Status checks use ww browser status. Shutdown uses ww browser stop. The dispatcher doesn’t need to know the browser service is different — it just routes the subcommands.
The service architecture means Workwarrior is extensible at the seam that matters. You can add a service without touching the dispatcher. You can override a service per-profile without modifying the global service. You can inspect the full service inventory from ww help without reading source code.
New weapons are services. New data integrations are services. New export formats are services. The 25+ service domains in the current release grew this way — each one is a directory under services/, each one follows the same contract, each one was added without modifying the ones that existed before it.
The service architecture is not a framework. There’s no base class to inherit, no decorator to register. It’s a filesystem convention and a contract. Conventions are simpler than frameworks, break less often, and are easier to reason about when something goes wrong.
Everything is a service. When in doubt, make it a service.
]]>The result: profiles can carry 100+ UDAs covering project metadata, financial fields, compliance tracking, people, equipment, and more — and the browser UI renders all of them in the task inline editor.
A UDA is a field definition in .taskrc. You declare the field name, type, label, and optional default value. Once declared, every task can carry that field.
uda.client.type=string
uda.client.label=Client
uda.estimate.type=duration
uda.estimate.label=Estimated Duration
uda.billable.type=numeric
uda.billable.label=Billable Hours
These are now first-class fields on every task in the profile. task add "Design review" client:acme estimate:2h billable:0 creates a task with those custom fields populated.
Workwarrior maintains a UDA registry per profile with source classification:
[github] — injected by Bugwarrior from issue tracking services[extension] — added by TaskWarrior extensions or hooks[custom] — defined by the user via ww profile uda addww profile uda list # All UDAs with source badges
ww profile uda add goals # Interactive creation wizard
ww profile uda remove <name> # Remove with safety warnings
ww profile uda group work # Group UDAs for batch operations
ww profile uda perm goals nosync # Set sync permissions per-UDA
The source badges matter for sync. A [github] UDA is owned by Bugwarrior — you probably don’t want to push changes to that field back to GitHub. A [custom] UDA is yours — sync permissions are yours to set.
ww profile uda perm <name> nosync marks a UDA as excluded from the github-sync engine. This prevents custom internal fields from appearing in GitHub issue labels or comments during two-way sync.
This is the kind of detail that breaks integrations in the wild: you add a priority-internal UDA that maps to your team’s internal priority scale, and suddenly it’s showing up as a GitHub label because the sync engine doesn’t know it’s internal. The permission system prevents that.
The browser UI’s task inline editor renders all UDAs defined in the active profile. You don’t configure this — it reads the profile’s .taskrc, discovers all UDA definitions, and builds the edit form dynamically.
This means a profile with client, estimate, billable, sprint, and component UDAs gets a task editor with all five fields, correctly typed (text inputs for strings, numeric inputs for numbers, duration pickers for durations). The profile with no custom UDAs gets the standard task editor.
UDAs can contribute to TaskWarrior’s urgency score. If billable hours is high, the task should float up in priority. If sprint is the current sprint number, active sprint tasks should be more urgent.
ww profile urgency # Interactive urgency coefficient tuner
The tuner shows all available urgency coefficient inputs — due date weight, priority weight, age weight, tag weights, and custom UDA weights — and lets you adjust them with an interactive prompt. The result is written to the profile’s .taskrc.
Per-profile urgency tuning is the right abstraction. Your work profile might weight client UDA heavily (client work is always more urgent). Your personal profile doesn’t have a client UDA and weights due date proximity more.
100+ UDAs covering: project metadata (phase, epic, component, sprint, story points), financial fields (estimate, actuals, billable, rate), compliance (owner, reviewer, approval date, compliance tag), people (assignee, stakeholder, reporter), and equipment (asset ID, location, maintenance date).
These aren’t built-in. They’re documented patterns in docs/setups/ that users can apply to their profiles using ww profile uda group <name>. The templates are starting points, not requirements. The data model is yours.
Building replacements for any of these tools would mean rebuilding years of accumulated design decisions and then maintaining those decisions indefinitely. Wrapping them means the tools stay excellent, the communities keep them current, and Workwarrior builds only the layer that didn’t exist.
The thing that didn’t exist was the connection layer. TaskWarrior doesn’t know about TimeWarrior. Neither of them knows about JRNL. None of them have a concept of a “profile” — an isolated workspace that all four tools share. None of them have a unified command surface. None of them ship a local web UI.
The connection layer — profile isolation, unified commands, natural language translation, browser dashboard, GitHub sync, weapons — is thin relative to the underlying tools. The underlying tools do the heavy lifting. Workwarrior adds the wiring.
This is the right decomposition. The alternative, a monolithic productivity system that handles tasks, time, journaling, and accounting in a single codebase, exists (several of them). They’re all trapped in a maintenance cycle that gets heavier as the feature surface grows. Workwarrior’s feature surface is bounded by definition: it’s the surface between tools, not the tools themselves.
There’s an tools/acknowledgements.md in the repo. It lists every tool, the maintainers, the license, the upstream repo. This isn’t a legal requirement — it’s a design value. Workwarrior works because these projects exist. The people who built them deserve credit by name.
The extension registry (ww extensions) takes the same approach. TaskWarrior has a rich ecosystem of community hooks and extensions. Workwarrior indexes them, makes them searchable, and makes them installable from one command. The registry celebrates the ecosystem rather than hiding it.
When a user discovers that ww gun is powered by a Rust binary called taskgun written by hamzamohdzubair, and follows the link to the GitHub repo, that’s a win. The attribution is explicit. The dependency is visible. The user can contribute to taskgun directly if they want to improve the gun weapon.
There are cases where wrapping breaks down. The wrapper needs to stay thin — when it gets thick, it’s usually a sign that a tool needed a patch rather than wrapping.
The two-way GitHub sync engine is the closest case. There’s no off-the-shelf bidirectional TaskWarrior ↔ GitHub sync solution that fits the profile model. That layer had to be built. Ten library files, a conflict resolution algorithm, field mapping, annotation↔comment sync. It’s the highest-fragility part of the codebase because it’s the part that was actually built from scratch rather than wrapped.
Everything else wraps. The sync engine builds. The difference in fragility is instructive: the built parts are where the complexity lives.
When working at the interface layer reveals a limitation in an underlying tool, the right move is to contribute upstream rather than work around it. The profile model revealed several edge cases in how TaskWarrior handles hook execution with non-standard TASKRC paths. Those were reported upstream.
The wrapper relationship is bidirectional. Workwarrior depends on these tools and owes them the bugs found while using them in unusual ways. The upstream communities get better test coverage. The tools get better. Workwarrior benefits directly.
This is what “open source as it gets” means in practice. Not just a public repo and an MIT license. Using the ecosystem, attributing it, finding and reporting bugs, contributing back where possible, being explicit about what you depend on. The whole system works better when the connection layer takes those obligations seriously.
]]>Workwarrior went the other direction. The heuristic engine is the primary interface. AI is optional, disabled by default, and explicitly opt-in. If you want to type natural language commands, you can — but they go through 627 regex rules first, and only reach an LLM if nothing matches.
This is a deliberate philosophy, not a cost-cutting measure.
Determinism. A heuristic rule either matches or it doesn’t. The output for a given input is always the same. An LLM produces different outputs for the same input on different runs, different days, different model versions. For a system that writes to your task database and time tracking records, determinism matters.
Latency. A regex match takes microseconds. An LLM API call takes seconds, plus the network round trip. For someone running ww browser as a persistent dashboard, heuristic commands feel instant. LLM commands feel like waiting.
Privacy. The heuristic engine processes everything locally. A task description that goes to an LLM API leaves your machine. For professional or client work, that’s a meaningful distinction.
Reliability. The heuristic engine works offline. It works when your LLM provider is down. It works when you’re in a coffee shop with unreliable internet. It works always.
The most interesting part of the heuristic/AI relationship is the feedback mechanism. Every CMD submission is logged as JSONL: input, route (heuristic or AI), output, success status. Running ww compile-heuristics --digest reads that log and converts successful AI translations into new heuristic rules.
This creates a loop: the AI handles the edge cases the heuristics can’t, those edge cases become heuristic rules over time, the AI handles fewer things, the heuristics handle more. The AI dependency decreases through use.
It’s a case where AI earns its place by making itself less necessary. The value isn’t persistent dependence — it’s seeding the rule set with patterns that cover real usage.
The cases where AI adds genuine value are the cases where the heuristic coverage is thin: unusual phrasings, compound commands with unusual structure, commands that combine semantics in ways the compiler didn’t anticipate.
"Flag the server migration task as needing review before the deadline"
That’s not a standard imperative, declarative, or shorthand phrasing. It’s an unusual sentence that a human would understand immediately. The heuristic engine probably misses it. The LLM handles it.
After the --digest run, that phrasing becomes a rule. The next person who types something similar gets heuristic speed.
# config/ai.yaml
mode: off # Default
# mode: local-only # Ollama only — no data leaves machine
# mode: local+remote # Local first, remote fallback
Three modes. Default is off. local-only is for people who have ollama running locally and want AI fallback without external API dependencies. local+remote for people who want the full fallback chain.
Per-profile overrides in profiles/<name>/ai.yaml. Work profile might have AI off (deterministic commands for professional tasks). Personal profile might have AI on (more relaxed about sending journal entries to an API).
The controls are available from ww ctrl and from the browser CTRL panel. No restart required. Toggle AI mode mid-session.
The point is: you decide. The heuristics work without AI. AI helps when you want it to. The system doesn’t require a subscription.
]]>services/<category>/. The ww dispatcher discovers it by scanning for executables. No registration step. No config update. Write the script, make it executable, it’s available as ww <category>.
Here’s a minimal service in full:
#!/usr/bin/env bash
set -euo pipefail
source "$WORKWARRIOR_BASE/lib/logging.sh"
USAGE="ww myservice — one-line description
Usage: ww myservice <list|info|add>
"
case "${1:-}" in
--help|-h)
echo "$USAGE"
exit 0
;;
list)
# implementation
log_info "Listing things..."
;;
info)
[[ -z "${2:-}" ]] && { log_error "info requires a name"; exit 1; }
log_info "Info for: $2"
;;
*)
log_error "Unknown subcommand: '${1:-}'"
echo "$USAGE"
exit 1
;;
esac
That’s the contract. Five requirements:
#!/usr/bin/env bash + set -euo pipefail--help / -hlib/logging.shThe dispatcher (bin/ww) routes ww myservice list to the list case branch. The help output appears in ww help. The service is available from the browser UI CMD panel immediately.
Services at profiles/<name>/services/<category>/ shadow global services. This means you can have a per-profile version of any service. ww myservice in the work profile runs the work-profile version; in the personal profile it runs the global version.
This is useful for per-profile customizations that shouldn’t affect other contexts. A work profile might have a specialized export service. A client profile might have a service that integrates with the client’s specific tooling.
docs/guides/services/service-development.md describes three service tiers:
Tier 1 — Simple — single-file script, direct TaskWarrior/TimeWarrior calls. Appropriate for services that wrap a single tool command or do simple data reads.
Tier 2 — Compound — multiple subcommands, uses lib functions for profile management. Appropriate for services with lifecycle (create/list/delete/backup patterns).
Tier 3 — Complex — state management, external APIs, background processes. Appropriate for services like github-sync that maintain persistent state across invocations.
Most new services start at Tier 1 and grow if needed. The pattern is identical across tiers — the difference is how much of the lib you reach into.
The architecture is a consequence of the profile model. Because everything resolves through environment variables, a service doesn’t need to know which profile it’s running against. It reads $WORKWARRIOR_BASE, calls lib functions with the right paths, and the isolation is handled automatically.
This is also why services are safe to contribute. A new service in services/my-extension/ touches nothing that already exists. It can’t break the sync engine. It can’t break the browser UI. It can’t break the CLI dispatcher (unless it introduces a naming conflict, which the dispatcher checks for at startup).
The extension surface is designed to be safe. Build services. Build weapons. Build profile-level customizations. The architecture gets out of the way.
]]>ww/system is the directory that doesn’t ship. It’s the project’s internal coordination layer — planning documents, task boards, fragility registers, agent role definitions, gate contracts. Users never see it. But it’s the reason the codebase is coherent.
Describing it as “documentation” is underselling it. It’s an operating model for a codebase that’s complex enough to need one.
A bash codebase with 24 library files, a bidirectional sync engine, a Python web server, and a compiler that generates regex rules has failure modes that aren’t obvious from the code. The sync engine can corrupt data in two places at once. The shell integration injects functions into every shell session — a bug there affects every command a user runs. The CLI dispatcher routes everything — a routing error silently misdirects commands.
Without a way to classify risk and enforce process around high-risk changes, the natural tendency is to edit files and see what breaks. In a project with irreversible failure modes, that’s not acceptable.
The fragility register classifies every major subsystem. HIGH fragility means changes require an extended risk brief, explicit write scope, and adversarial Verifier sign-off before merge. MEDIUM means standard process. LOW means standard process with lighter documentation.
The agent model defines four always-active roles:
Orchestrator — owns the task board, writes contracts, makes merge decisions. Never writes production code. The constraint is critical: if the Orchestrator writes code, it loses the perspective needed to evaluate that code.
Builder — works within explicit write scope defined by the Orchestrator. Produces a risk brief before touching any file in the write scope. The risk brief is required — it forces the Builder to think through failure modes before editing.
Verifier — adversarial test execution. Runs the test suite, looks for regressions, produces a signed checklist. Never implements. The Verifier’s job is to find problems, not fix them.
Docs — updates CLAUDE.md files, user documentation, and help strings after merge. Runs last, after the implementation is confirmed correct. Documentation written before code is verified tends to describe intended behavior rather than actual behavior.
No agent self-approves. The Orchestrator’s task card is a contract — the Builder implements against it, the Verifier validates against it, the Docs agent updates to reflect it.
Gate A: Spec complete. Contract written, scope agreed.
Gate B: Implementation ready. Risk brief produced.
Gate C: Tests pass. Verifier sign-off.
Gate D: Docs updated. Task closed.
No skipping gates. A change that skips Gate C and goes straight to Gate D is a change that’s not verified. A change that skips Gate B is a change without a risk brief — meaning nobody thought through what could go wrong before touching the code.
The gate model isn’t bureaucracy for its own sake. It’s the minimum process needed to keep irreversible failure modes from reaching production.
The same agent model — Orchestrator, Builder, Verifier, Docs — is available to users via ww mcp install. The MCP server exposes TaskWarrior data to AI agents. The control plane architecture you’d use to build a project with these roles is the same one that builds Workwarrior.
This means the system is self-demonstrating. The development process produces a tool that implements the development process. Users who want to bring the same coordination model to their own projects can deploy it directly.
It’s a strange loop. The cleaner we keep ww/system, the better the tool that comes out of it.
Bugwarrior — one-way pull from 20+ issue tracking services into TaskWarrior.
ww github-sync — two-way bidirectional sync between individual tasks and GitHub issues.
Use both. They handle different parts of the problem.
Bugwarrior is a pull tool. Configure it with API credentials for your services — GitHub, GitLab, Jira, Trello, Bitbucket, and 17 more — and i pull brings all your open issues into TaskWarrior as tasks.
ww issues custom # Configure services interactively
i pull # Pull from all configured services
i status # Show what was pulled
The tasks it creates carry injected UDAs: githubissue, githuburl, githubrepo, githubauthor. These are tagged [github] in the UDA source registry — you can see them with ww profile uda list.
Bugwarrior is strictly one-way. It reads from the service and writes to TaskWarrior. Changes you make to a bugwarrior-created task in TaskWarrior don’t flow back to GitHub. That’s where github-sync comes in.
The two-way sync engine links individual TaskWarrior tasks to individual GitHub issues. Once linked, changes flow in both directions: update the task locally, it updates the issue. Comment on the issue, the annotation appears on the task.
ww issues enable <task> <issue#> <org/repo> # Link
ww issues sync # Two-way sync all linked
ww issues push # Push local → GitHub only
What syncs bidirectionally:
What pulls only (GitHub → TaskWarrior):
Conflict resolution is last-write-wins with a configurable conflict window. If both sides changed within the window, the sync reports the conflict rather than silently overwriting.
The sync engine is the highest-risk part of the codebase. Ten files in lib/. Classified HIGH FRAGILITY.
Getting it wrong means data loss in two places simultaneously: a task annotation deleted that was actually a comment on a critical issue, a status change propagated incorrectly that closes an issue that shouldn’t be closed. These failures are hard to detect and harder to reverse.
The development protocol for these files: extended risk brief before any change, explicit write scope, Verifier sign-off before merge, integration tests required. This isn’t excessive — it’s proportionate to the failure modes.
The intended workflow:
i pull to get all your issues as tasks.ww issues enable on those.i pull refreshes the full issue list. ww issues sync keeps your linked tasks bidirectionally current.The Bugwarrior-created tasks and the github-sync-linked tasks can coexist in the same TaskWarrior profile. Bugwarrior stamps its tasks with the [github] source badge on the UDA. github-sync manages its own state file. They don’t interfere with each other.
The current set: Gun, Sword, Next, Schedule. The roadmap: Bat, Fire, Slingshot (purposes TBD). They appear in the browser sidebar as a weapons bar.
Sword is native to ww — no external binary. It takes a single task and splits it into N sequential subtasks with dependency chains.
ww sword 5 -p 3 # Split task 5 into 3 parts
ww sword 5 -p 4 --interval 2d # 2-day intervals between parts
ww sword 12 -p 2 --prefix "Phase" # Custom prefix
Each subtask gets:
The dependency chain is the key. TaskWarrior’s dependency model prevents a task from being completed if it has uncompleted dependencies. Sword creates a strictly sequential chain — you can’t mark “Part 3 of: Ship API” done until “Part 2 of: Ship API” is done. This is the right behavior for a task that genuinely has ordered phases.
The parent task gets archived (done) after the split, since it’s now represented by the subtask chain. The context — project, tags, urgency tuning — carries forward.
Gun wraps taskgun, a Rust binary for bulk task series generation. Give it a series definition and it creates multiple related tasks with deadline spacing.
ww gun <args>
The wrapping is thin: Gun respects the active profile (reads TASKRC/TASKDATA from env), passes arguments through to taskgun, and handles the TaskWarrior output. It appears as ww gun rather than requiring the user to know taskgun’s command syntax.
Next wraps the next binary — a CFS (Completely Fair Scheduler) inspired algorithm that recommends the optimal next task based on urgency scores, deadline proximity, and current context.
ww next
One command, one recommendation. The recommendation factors in TaskWarrior’s urgency score plus context signals. When you don’t know what to work on, this is the answer.
Schedule wraps taskcheck, an auto-scheduler that assigns time blocks to tasks across your calendar.
ww schedule
All weapons follow the same rules:
POST /cmd in the browser UI — weapons are available from the weapons bar--helpThe weapons bar in the browser UI shows icons for each weapon. Clicking opens a panel that exposes the weapon’s parameters as a form, so you don’t have to remember the CLI syntax.
The planned weapons — Bat, Fire, Slingshot — don’t have specified purposes yet. The naming scheme is intentional: tools that cut, split, and shape task data. What they shape is still being figured out.
]]>ww browser.
That constraint — no external dependencies — shaped everything. It’s not a limitation we worked around; it’s a design requirement we built from.
A UI with an npm build pipeline has install friction. npm install fails for reasons unrelated to your code. Build steps break. Dependencies go stale. Someone with a fresh machine needs to debug package-lock.json before they see anything in the browser.
The alternative: a Python ThreadingHTTPServer that serves static HTML/CSS/JS from disk, a REST API of 20 endpoints, and a Server-Sent Events channel for real-time updates. The whole server is a single Python file and a directory of static assets.
Start it with ww browser. It’s running on localhost:7777 in under a second.
services/browser/
server.py ThreadingHTTPServer, REST API, SSE
static/
index.html Single-page app shell
style.css Dark terminal aesthetic, 15+ panel layouts
app.js Panel management, command routing, SSE client
ThreadingHTTPServer handles SSE connections without blocking. An SSE connection holds a socket open — the server pushes profile change events down that socket whenever something changes. Concurrent POST /cmd requests are handled in separate threads without queuing behind the SSE socket.
Static files are served directly from disk on each request. No caching, no preprocessing. Change a CSS file and refresh the browser — the change is visible immediately without a server restart.
The biggest risk in a browser UI that executes system commands is remote code execution. POST /cmd executes a ww subcommand — that has to be constrained.
The constraint: an ALLOWED_SUBCOMMANDS frozenset. Every POST /cmd request is validated: the first token must appear in the frozenset. No sh -c. No eval. Unknown subcommands return 400.
This means the attack surface is bounded. An XSS in the UI can only execute valid ww subcommands. Valid ww subcommands can’t exec arbitrary shell commands. The security model is explicit and auditable.
15+ panels covering everything in the active profile:
The SSE channel pushes profile switch events. Switch profiles from the CLI — the browser updates in real time.
No npm means no React, no Vue, no TypeScript. The app.js is vanilla JavaScript. For 15+ panels with real-time updates and a command routing layer, that’s manageable. It’s not a framework — it’s a single-page app written carefully in the language that runs in every browser without installation.
The performance is fine. The bundle size is zero. The install step for the browser UI is “you already have Python.”
]]>627 compiled rules. 19 command domains. 6 phrasing variations per command. No network. No latency. No API key. You type “add a task to review the budget due friday” and the rule for imperative task creation with a date expression fires in microseconds.
If AI is required for basic commands, the system has an external dependency for routine operations. That’s fine when internet is reliable and latency is acceptable. It’s a problem when you’re on a plane, when your LLM provider is down, when you don’t want to send your task descriptions to a third party.
The heuristic engine makes the CMD service useful offline and without configuration. Install workwarrior, run ww browser, type commands in plain English — it works before you’ve set up a single LLM provider.
Six phrasing variations per command, with different confidence scores:
| Variation | Confidence | Example |
|---|---|---|
| Passthrough | 1.0 | task add review budget |
| Imperative | 0.95 | add a task to review the budget |
| Declarative | 0.90 | I need a task for reviewing the budget |
| Interrogative | 0.90 | can you create a task to review the budget |
| Shorthand | 0.90 | task: review budget due friday |
| Verbose | 0.85 | I would like to add a new task for reviewing the budget |
Date expressions are normalized: “tomorrow”, “next week”, “friday”, “end of month”, “in 3 days” all map to the correct TaskWarrior date format.
Compound commands are split on conjunctions and matched independently:
"finish task 5 and stop tracking"
→ task 5 done
→ timew stop
"add task review and start tracking time"
→ task add review
→ timew start review
If any segment fails to match above the confidence threshold (0.8), the entire compound goes to AI. This is the right behavior — a half-translated compound command is worse than no translation.
Rules aren’t written by hand. ww compile-heuristics scans the codebase — bin/ww case branches, config/shortcuts.yaml, config/command-syntax.yaml — generates regex patterns, validates them against a synthetic corpus, resolves conflicts, fills coverage gaps, and writes the output.
The --verbose flag shows every rule with test results. The --digest flag reads services/cmd/cmd.log — every CMD submission is logged as JSONL — and converts successful AI translations into new heuristic rules.
That last part is the self-improvement loop. Every time the AI handles a command the heuristics couldn’t, that’s a potential new rule. Run --digest regularly and the AI dependency shrinks over time.
Input
→ Compound split (if "and"/"then"/"also"/"plus")
→ Each segment: heuristic match at confidence > 0.8
→ No match? → AI fallback if configured
→ AI not configured? → Clear error message
The error message on a heuristic miss is explicit: “No matching rule. Try the full ww command or enable AI mode.” That’s better than silently failing or silently sending data to an API.
AI is an option, not a requirement. Most commands go through heuristics. The engine gets better over time. The AI dependency decreases.
]]>