[Adopter] LNXDrive

[montfort]

Project name & repository

LNXDrive — https://github.com/StrangeDaysTech/lnxdrive (público)

Organization / responsible maintainer

Strange Days Tech — @montfort

Stack & domain

LNXDrive is a cloud-storage synchronization client for Linux, written in Rust (1.75+) with a clean/hexagonal architecture. It runs as a user-level systemd service (lnxdrive-daemon), talks to desktop integrations over D-Bus (com.strangedaystech.LNXDrive), and exposes a FUSE filesystem for files-on-demand. Native integrations for GNOME, KDE Plasma, COSMIC and GTK3 desktops (shell extensions, Nautilus overlays, GOA provider), multi-provider/multi-account (OneDrive, Google Drive, Dropbox). Built with structured JSON logs, Prometheus metrics, and a full audit trail. GPL-3.0-or-later. Status: early development (road to v0.1.0-alpha-1).

Domain note: this is deliberately a different domain from Sentinel (a Go backend service). LNXDrive is a Rust system-level daemon + desktop-integration app — FUSE, D-Bus, systemd, multi-crate workspace (engine, gnome, preferences, packaging, testing). That distance is the point: it stresses the governance patterns in a place Sentinel never touched.

Versions adopted

fw-4.19.0 / cli-3.16.0

Adoption path

Path A — new project (StrayMark from day one)

What feedback do you commit to send?

• Charter telemetry (.straymark/charters/CHARTER-NN.telemetry.yaml at close)
• External audit results (the external_audit array — dual/multi-model calibration)
• Pattern candidates (anti-patterns or disciplines you discover during execution)
• Format friction (where the Charter / document templates got in your way)
• CLI bugs and documentation gaps

N-context — are you validating an existing pattern?

Yes — LNXDrive is intended as the N=2 validation for patterns first documented at N=1 in Sentinel, now exercised in a different domain (Rust system daemon + desktop integration vs Sentinel's Go backend). It already runs Charters with external audits (the v0.1.0-alpha-1 road Charter is in progress, with dual-audit infrastructure landed in #37/#38), so the telemetry pipeline is real, not aspirational.

Primary patterns to re-validate from this second domain:

• Polish Charter as debt-detection (the "surface declaration without wiring" anti-pattern) — especially interesting here, where a declaration can be wired across crate boundaries, D-Bus interfaces, or systemd units, so "declared but not wired" has more surface area.
• Charter-chain evolution (pre-declare SpecKit refresh; post-close audit-driven amendment).

If these hold in a FUSE/D-Bus/multi-crate context, they clear the N=1 → N=2 gate for CLI crystallization. If they don't transfer cleanly, that mismatch is itself the signal worth reporting.

Expected feedback cadence

Per Charter close (telemetry + external-audit results), with ad-hoc issues for CLI bugs and doc gaps as they surface during early development.

How you'll cross-link findings

Every actionable finding goes in an Issue using the "Adopter feedback / upstream finding" template, referencing this discussion's number so each finding stays tied to LNXDrive and its N-context.

Acknowledgements

• I've read the Adoption Guide and the Adopter Feedback guide.
• I understand telemetry stays in my repo by default — sharing is manual, and I'll anonymize anything sensitive before posting it upstream.