Living Document Notice
Published 2026-09-29. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.
The Bosun Horizon
Summary
The evolution of personal knowledge systems requires transitioning experimental prototypes into deterministic production engines. Scripted wrappers and interpreted language runtimes introduce non-deterministic execution paths, memory bloat, and fragile cross-platform dependencies.
The Bosun development roadmap centers on three foundational milestones: migrating the core parsing runtime to a native Rust engine, formalizing the OPS-1 agent containment specification, and implementing deterministic link resolution algorithms across distributed note hierarchies.
Architectural Evolution Across Development Horizons
Bosun transitions through structured implementation phases to preserve backward compatibility with existing file archives while continuously reducing runtime latency.
+-------------------------------------------------------------+
| Phase 1: Shell & Python Prototypes |
| (Ad-hoc scripts, CLI wrappers, external grep) |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| Phase 2: Modular POSIX Daemon Fleet |
| (Decoupled C/Go daemons, Unix sockets, inotify) |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| Phase 3: Unified Native Rust Core |
| (Zero-copy Tree-sitter, WASM targets, strict OPS-1) |
+-------------------------------------------------------------+
Phase 1 validated file-first workflows using shell scripts and Python utilities. Phase 2 decoupled these tools into independent POSIX daemons communicating over domain sockets. Phase 3 compiles the entire core parser and index pipeline into native Rust binaries and WebAssembly artifacts, eliminating external interpreter dependencies.
Milestone Technical Comparison
The progression from scripting wrappers to a unified systems engine brings clear operational improvements. The table below details target specifications across the three architectural phases.
| Technical Metric | Phase 1 (Scripted Wrappers) | Phase 2 (POSIX Daemons) | Phase 3 (Native Rust Core) |
|---|---|---|---|
| Binary Size / Runtime Dependency | Python 3.11 + Shell (~120 MB) | Decoupled Binaries (~15 MB) | Single Static Binary (< 8 MB) |
| Cold Indexing Rate | ~450 notes / sec | ~2,800 notes / sec | > 18,000 notes / sec |
| Parser Memory Arena | Dynamic heap allocations | Per-process buffers | Contiguous slab arenas (24B/node) |
| Agent Sandboxing Model | Host subshell execution | Basic cgroups v1 limits | Formal OPS-1 Linux namespaces |
| Cross-Platform Target | Linux / macOS POSIX only | Linux / macOS POSIX only | Native Linux/macOS + Browser WASM |
Compiling to WebAssembly in Phase 3 allows the identical parsing engine to run in browser clients, enabling 100% local document conversion workflows without server interaction.
Deterministic Link Resolution Algorithm
Wikilink resolution in flat-file note collections often introduces ambiguity when multiple notes share identical titles across different subdirectories. The native engine implements a deterministic path resolution heuristic that eliminates ambiguity without requiring full directory scans.
use std::collections::HashMap;
use std::path::{Path, PathBuf};
pub struct LinkResolver {
slug_index: HashMap<String, Vec<PathBuf>>,
}
impl LinkResolver {
pub fn resolve_reference(&self, current_file: &Path, raw_link: &str) -> Option<PathBuf> {
let clean_slug = slugify_link(raw_link);
let matches = self.slug_index.get(&clean_slug)?;
// Priority 1: Match within identical parent directory
if let Some(parent) = current_file.parent() {
for target in matches {
if target.parent() == Some(parent) {
return Some(target.clone());
}
}
}
// Priority 2: Shortest relative path distance
matches.iter().min_by_key(|path| {
path.components().count()
}).cloned()
}
}
fn slugify_link(input: &str) -> String {
input.to_lowercase().replace(' ', "-")
}The algorithm checks the calling document’s immediate directory before falling back to shortest relative path depth, ensuring predictable resolution across complex vault layouts.
The Compilation Invariant
The architectural invariant governing the native engine requires that all core parsing, wikilink resolution, and frontmatter serialization operations must execute deterministically without dynamic heap allocations during steady-state AST traversals.
Run the test suite across the unified native workspace:
cargo test --workspace --all-targets -- --nocapture- Directus Target: bosunpkm-blog
- Garden Source Reference: MOC - Bosun PKM Engine, MOC - Bosun PKM Tools, MOC - Local-First Systems and Synchronization