Current status: Linux V0.2 is accepted for Mick's current use, with source published and tagged v0.2.0. Its control plane adds explicit capabilities, tools, execution, receipts and plugins. Plugins remain trusted in-process code; broader Linux compatibility and installed launcher matching remain unqualified.
The problem
Ordinary model conversations are poor foundations for consequential project work. Context drifts, a confident answer can masquerade as proof, and the record of what actually ran is easy to lose. B.O.T.S. exists to turn AI-assisted work into bounded campaigns with inspectable inputs, outputs and acceptance decisions.
The system Mick directed
B.O.T.S. began as a custom harness for coordinating bounded AI workers and grew into a native Linux desktop built around the same operating principles. Campaign workers receive explicit contracts, operate inside defined authority boundaries and leave durable artifacts that can be checked after the conversation is over. The desktop adds persistent application state and native workflows without promoting model output into authority.
Campaign workers remain text-only: they have no shell, filesystem, Git, plugin or tool access, and cannot recursively delegate. The harness owns execution and persistence. V0.2’s separate control plane adds explicitly granted tool, process, Git and plugin consumers; their implementation does not confer autonomous authority on those campaign workers.
Mick framed the problems, designed the operating constraints, directed staged implementation campaigns and retained the final acceptance boundary. AI tooling was used heavily to implement, test and review the code; the site does not pretend otherwise.
Constraints that mattered
- Worker scope and permissions have to be explicit.
- Results need to survive beyond a chat transcript.
- Candidate identity must be sealed before validation.
- Tests and reports must be reproducible against the named candidate.
- Technical completion, substantive acceptance, commit authority and later repository consequences remain separate states.
- A worker must not be treated as the final judge of its own work.
- Publication remains a separate human decision.
What proved difficult
The hard parts were not prompt decoration. They were lifecycle, persistence and concurrency behaviour: keeping repository state coherent, controlling data-root effects, preserving SQLite durability, handling cancellation and close paths, evolving archive interchange without losing provenance, making backup and whole-installation restore recoverable, and exposing campaign execution through the desktop without weakening the headless authority model.
Later compatibility work also found that a SQL expression accepted by newer SQLite builds could overflow the parser on SQLite 3.45.1. The repair was handled as a bounded compatibility defect rather than hidden behind a newer development environment.
How failure was handled
Work moved through narrow phases with explicit acceptance records. Failed or blocked candidates were not silently promoted. Phase 10 itself had earlier candidates rejected by independent review, repaired inside the approved fence and resealed before the accepted candidate was validated. Findings became bounded repairs and regression tests rather than narrative exceptions.
The same distinction applies after implementation: a green test suite is technical evidence, not automatic substantive acceptance, commit authority or publication authority.
Implemented today
The public repository contains the original manifest-driven campaign harness, the native Linux v0.1 application closed with limitations through Phase 12, and the accepted V0.2 control plane. The Phase 10 baseline includes persistent conversations, streaming generation and cancellation, provider and model configuration, deterministic context and content-addressed attachments, search and exact navigation, inspection and provenance surfaces, transcript and archive interchange, backup and whole-installation restore, and a native campaign dock over the headless campaign engine.
Phase 10 adds attempt-addressed campaign evidence, explicit preflight and one-shot approval binding, truthful cancellation, selected-versus-cumulative cost accounting, worker regeneration, synthesis rerun with staleness classification, and matching headless CLI operations.
Later main contains the SQLite 3.45.1 compatibility repair and CI v1, followed by Phase 11. Phase 11 adds command-palette and keyboard workflows, richer message rendering, folders, pins and deletion, workspace restoration, model-selector and desktop presentation work, and a standalone Linux build path for the CLI and desktop. Its final repair makes provider/backend/router stream ownership explicit and drains owned cleanup before application resources are released, preserving valid terminal completion without consuming irrelevant response tails.
Public main also adds provider-managed OpenRouter context and Archive v3 preservation. This mode uses deterministic local selection with a heuristic context estimate and provider final admission; it does not promise exact token accounting or guaranteed fit. Existing exact-accounting adapters retain their separate contract.
The subsequent Phase 12 wave 2 commit aligns provider failure reporting with the canonical remote-outcome classification and connects caller-supplied completion deadlines to HTTP transport timeouts. It adds regression coverage and loopback TCP tests for malformed streams, failures before terminal completion, trailing garbage, cancellation, timeout settlement and resource ownership, alongside backup/restore crash tests.
Later packaging work pins Nuitka 4.2, freezes Python UTF-8 mode and normalizes filesystem-byte arguments in generated entrypoints. Application icon work embeds size-specific SVG badges in Qt and supplies desktop-entry and hicolor resources for wheels and standalone bundles. It sets application/window icons and a shared launcher identity; it does not install shortcuts or change desktop settings.
V0.2 adds a shared capability/authority seam with explicit scope, expiry and budgets; durable execution queues and receipts; bounded local tools and an offline egress consumer; bounded code/process execution; a Git consequence ladder; self-authored plugins; and desktop integration. Crash recovery records uncertain in-flight outcomes as terminal UNKNOWN rather than guessing. Tool definitions and plugin manifests request capabilities and confer no execution authority by themselves. The release also includes the earlier schema-v2 provider-configuration line, which adds the built-in non-streaming local OpenAI-compatible provider while preserving schema-v1 behavior.
Validation evidence
The accepted Phase 10 candidate recorded a complete-repository T4 result of 1504 passed, 1 skipped, exit 0. Independent review completed its verification milestones with no candidate-changing defect, but the reviewer failed while emitting its final report. The final technical disposition, PASS_WITH_LIMITATIONS, is a labelled supervisor reconstruction rather than an oracle-authored final report. Accepted limitations remain documented rather than silently rewritten as resolved.
The Phase 10 review and validation used deterministic fake providers and offscreen Qt. They do not establish a real GUI session or live provider acceptance. Accepted regression-test gaps remain around synthesis-rerun independence and legacy-v1 freshness; the final outcome record preserves these alongside the product limitations.
CI v1 subsequently established a separate authoritative sharded T4 result against candidate 58fca2c7, in run 36682157600: 1597 passed, 0 failed, 0 errors, 1 permitted skip across 1598 collected tests. The workflow is dispatch-only. That CI result belongs to this exact candidate, not automatically to every later descendant of main.
The 5 October Phase 11 closure record reports final source T4 of 2189 passed, 1 permitted opt-in skip, 0 failures/errors, 71/71 frozen provider-cleanup cases passed, and 156/156 M7 package checks passed, with no skips or unexecuted cases in those two package gates. These results belong to the retained final source and rebuilt standalone, not to later documentation bytes. Packaging validation is separate from T4 and uses offscreen desktop checks; its evidence is confined to the validated target, without a general Linux-distribution compatibility guarantee.
The public closure record distinguishes technical completion, subsequent human acceptance, commit authority and landing. Raw campaign evidence and the standalone remain outside the public product commit; no new public GitHub Actions run is linked for this final candidate. Earlier reports and test counts retain their historical subjects.
The Phase 12 closure record retains 2240 passed, 1 permitted skip, 0 failures/errors for its source candidate and 19/19 frozen obligations passed for a rebuilt standalone. It records Mick’s acceptance as PASS_WITH_LIMITATIONS on 6 October UTC. These are retained campaign results, not checks rerun for the documentation closeout; the public record does not establish independent byte-level verification of local seals or manifests. The retained run artifacts and executable are not in the public tree, and the latest public GitHub Actions T4 run still concerns the earlier CI v1 candidate.
The later Unicode-path repair commit separately reports 164 mandatory checks passed, 19 retained frozen cases passed, two loopback stalled-provider deadline trials passed, and 363/363 final artifact files verified unchanged. Its qualification is Forge with offscreen Qt, covering ASCII, accented and CJK/home-like paths, renamed Unicode executables, plain C locale startup and restore re-entry. It is not full T4, real-compositor, general Linux or arbitrary non-UTF-8 filename-byte qualification. Those results predate the subsequent icon commit and do not automatically validate its descendant. The icon implementation includes resource-rendering and launcher-identity tests, but no separate icon-specific validation result is supplied. This site audit inspected public source and tests without independently rerunning B.O.T.S. or verifying its standalone.
The V0.2 closure record reports a retained final full-suite result of exit 0 with zero failures on release-prepared bytes; it supplies no numerical test total. Release preparation also records producer-version and archive compatibility checks and freshly built sdist/wheel metadata at 0.2.0. The campaign seal covers 52 of 799 tracked release files, comprising the V0.2 delta and three version-bearing files. The record explicitly states that the remaining 747 pre-existing v0.1 files were neither sealed nor validated by that campaign; there is no whole-release seal. These statements retain their separate scopes. Raw campaign evidence remains unpublished, and no new public GitHub Actions run verifies this release. This audit did not independently rerun these checks or verify the local seal.
Current boundary
The V0.2 closure record reports Mick’s acceptance and source publication on 9 October Australia/Sydney. The public v0.2.0 tag points to release commit 0fffe894; current main subsequently adds the closure document. This establishes tagged source publication, with no GitHub Release, public standalone binary or product deployment established. The v0.1 standalone remains local and unpublished. AppImage remains conditional/deferred; Flatpak and Snap are outside the documented packaging path. Deferred work and any lifting of retained limitations require separate authority.
Plugins execute in the same process as the authority manager. Supervised-subprocess plugin execution is declared but not implemented; the capability seam is a policy/accounting layer, not a hostile arbitrary-code sandbox. The release’s threat model covers accidental, defective, compromised-in-scope and out-of-authority behavior, with tamper resistance dependent on keeping untrusted code out of that authority process. Repository identity binding retains an unproven inode-reuse limitation. Unknown Git commands/flags fail closed, and broad-approval rationale is recorded without a claim of automated quality scoring. V0.2 closure does not resolve these limits or the retained v0.1 limitations.
The accepted v0.1.0 artifact built with Nuitka 4.1.1 retains DEP-01: non-ASCII executable-path components can abort bots5 or bots5-desktop at startup. That artifact still requires an ASCII-only installation path; source installation is unaffected. The later rebuilt candidate reports scoped Unicode-path qualification and does not replace the accepted artifact or establish broader distribution compatibility. The historical closure’s DEP-01 wording remains applicable to its accepted artifact, rather than describing every later build recipe.
The icon resources are landed implementation, not proof of an installed desktop integration. The supplied desktop entry expects bots5-desktop on PATH. Installing launcher resources and checking actual pinned-launcher matching in a KDE session remain separate steps; no such installation or session verification is claimed here.
The Phase 11 closure supersedes the earlier unresolved provider-stream cleanup status for the corrected subject. Its finite ownership proof is not a global leak-free guarantee. That record retains 807 pytest warnings, including resource warnings, alongside observed pending restore-task diagnostics. Their allocation/ownership origins and individual harmlessness findings remain unestablished. Real credential-service operations remain unverified, and the Python/Nuitka toolchain retains its experimental qualification.
The unsupported historical migration downgrade remains accepted/carried and leaves partial database changes. Supported recovery restores attributable prior source or a verified pre-upgrade backup and migrates forward; no successful historical reversal is claimed.
Provider secrets, private operational context and material that is not intentionally public are not reproduced here.
Public boundary: This page follows the accepted Linux v0.1 and V0.2 closure records in public Git, distinguishing source publication, recorded acceptance and reported validation from binary distribution, process isolation and platform support. Provider credentials, private operational context and unpublished material remain excluded.