# FrankenRemote — RULEBOOK v1.0 Assessment Packet v5

**Repository:** `Dicklesworthstone/franken_remote` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `fdeb7a2ec079136e4d47a24138ce18d74b30d105` (2026-09-22 15:22:17 UTC, [Git-observed, High]) · **Last push:** 2026-09-22 (pin is HEAD at clone time) [Git-observed, High] · **Scope:** the pinned commit only, not HEAD. No releases; no tags observed on the assessed tree (0 GitHub Releases [External, High]). *Cold-reader note: "v1"/"v2"/… = drafts of this packet, not the repo's own versioning. "Bead" = the repo's issue-tracker unit (`.beads/issues.jsonl`). "RCH" = the maintainer's internal remote-execution harness (`rch exec`, worker `hz3`) — the packet could not find a public definition; treat RCH-referenced evidence as maintainer-operated, not independent.*

**Method (analyst):** shallow clone of HEAD checked out at the pin under `~/workspace/.scratch/franken_remote-verify` (verified non-empty). Read: root `Cargo.toml`, `Cargo.lock` (asupersync pin), `LICENSE` (verbatim), README (status statements, verification claims), `IMPLEMENTATION_STATUS.md` (full), `COMPREHENSIVE_PLAN_FOR_THE_DESIGN_OF_FRANKENREMOTE.md` v1.4 (structure + thesis skim), `SECURITY.md` (full), `CHANGELOG.md` (head), `.beads/issues.jsonl` (count), all 40+ `.github/workflows/*.yml` (listing only), `docs/decisions/*`, `results/latest/result.json` (head). Counted: `.rs` files/lines per crate, unsafe files by crate, `unimplemented!`/`todo!` sites (zero), unsafe-gate posture. Checked via GitHub API (2026-09-22): stars/forks, releases (none), CI runs for `rust-verification.yml` (recent failures on commits pushed before the pin), and check-runs for the pin (none registered). **Not done:** the workspace was never compiled, no test was executed, no benchmark or latency measurement was reproduced, no live Tailscale session was attempted, the design docs were not exhaustively read line-by-line, independent (third-party) coverage was searched with recall caveats only. Assessment date: 2026-09-22.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read); **[CI-observed]** is Tier 2 (seen executing on live CI pages — attests the suite *runs*, not that it is green); **[Maintainer claim]** asserted in README/docs, not independently executed; **[External]** independent sources; **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

---

## Hook

A 249,372-line [Counted, High], 13-crate Rust program — with zero `unimplemented!` sites [Counted, High] and 36 CI verification workflows — that its own README insists is *"not an installable remote desktop yet"* [Maintainer claim, High]. The most striking property of FrankenRemote is the discipline of its negative space: it owns almost nothing by design (Tailscale owns identity, asupersync owns the runtime, platform APIs own capture), and the enormous design corpus — a 1,439-line plan at v1.4, ~96 root-level design documents, 106 tracked design beads [Counted, High] — is devoted to the small amount of *policy* (freshness contracts, expiring input authority, bounded queues) that would make other people's infrastructure behave like one excellent remote workstation. This packet exists because the repository is two contradictory things at once: the most elaborate remote-desktop *design* in the FrankenSuite, and an early *implementation* with real executed test evidence that its own documentation repeatedly forbids you from mistaking for a product.

---

## TL;DR

- **What it is:** A Tailscale-identity-based remote workstation (the `frd` host daemon and `fr` client) in Rust, specified in a 1,439-line v1.4 design plan and early-implemented as a 13-crate workspace: ~249k first-party Rust lines / 742 files [Counted, High]. There is no complete application, no qualified live transport, and no hardware-qualified capture/codec path — the README and IMPLEMENTATION_STATUS.md say so in plain language [Maintainer claim, High].
- **Strongest evidence:** Implemented and *tested* vertical slices with exact verification receipts: remote-executed RCH gates at an earlier revision ran 236 tests with zero failures (cargo check, clippy, fmt, docs gates all green, exact source hashes) [Maintainer claim, High — the receipts are documented in IMPLEMENTATION_STATUS.md but were not independently re-run]; the four verification runs the docs cite (including the README's retained run) are independently confirmed green via the Actions API [CI-observed, High — greenness at the cited revisions, not the pin]; real QUIC/TLS integration tests against localhost (control-lease renewal, observation renewal) with documented scope limits [Maintainer claim, Medium]; real-QUIC software-HEVC X11 round-trip scenarios with forced-backpressure repair (claim 26) [Maintainer claim, Medium]; pointer/button injection exercised against real X11/XTest servers [Maintainer claim, Medium]; unsafe code confined to `fr-native` (40 files) and `fr-ffi` (2 files), with `unsafe_code = "forbid"` inherited workspace-wide [Code-verified, High]; asupersync 0.5.0 consumed as a *published* crates.io release, not a mutable sibling checkout [Code-verified, High]; and a README that disavows its own product status — an honesty posture matched by FrankenRedis's negative-evidence ledger.
- **Strongest doubts:** there is no product to use (no release artifact, 8 stars / 3 forks [External, High]); greenness at the pin is unestablished (the pin has zero registered check-runs; recent `rust-verification.yml` runs at earlier SHAs failed [CI-observed, Medium]); the test evidence is slice-scoped, with every important integration boundary explicitly unqualified (no live Tailscale/QUIC/H3, no hardware capture/HEVC, no macOS/Windows builds [Maintainer claim, High]); bus factor 1 (Jeffrey Emanuel) [Git-observed, High]; the license rider names OpenAI and Anthropic as Restricted Parties and bars them from use, benchmarking, testing, or analyzing the code — a non-OSI restriction that makes independent AI-lab evaluation literally unlicensable [Code-verified (license text), High]; and the 249k lines of code exist against a design that planned 194k with a hard ceiling of 250k — the ceiling is about to be hit before any complete application exists [Code-verified + Maintainer claim, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 3–4 — see §4.9). The packet ring-downs the brief's "Monitor" framing to Explore because executed test evidence on implemented policy slices (not merely a plan) is what the Rulebook calls substantive-but-unproven — but the ring is fragile and its revisit triggers are structural, not cosmetic.

---

## Quick Links

Pin-relative links (`blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105`); verified resolving 2026-09-22 [Verified, Medium]:

1. [Repository](https://github.com/Dicklesworthstone/franken_remote)
2. [README](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/README.md)
3. [License (with AI-lab rider)](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/LICENSE)
4. [Comprehensive design plan v1.4](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/COMPREHENSIVE_PLAN_FOR_THE_DESIGN_OF_FRANKENREMOTE.md) — 1,439 lines, 28 top-level sections (122 headers incl. subsections)
5. [Implementation status](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/IMPLEMENTATION_STATUS.md) — the implemented-slices ledger with verification receipts
6. [Security policy](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/SECURITY.md)
7. [Changelog](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/CHANGELOG.md)
8. [Wire protocol spec](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/PROTOCOL.md)
9. [Agent guide (build/verify discipline)](https://github.com/Dicklesworthstone/franken_remote/blob/fdeb7a2ec079136e4d47a24138ce18d74b30d105/AGENTS.md)
10. [CI: rust-verification workflow](https://github.com/Dicklesworthstone/franken_remote/actions/workflows/rust-verification.yml) — recent runs failing at earlier SHAs; pin has no registered check-runs

---

## Did You Know

The repository's 1,439-line design plan (v1.4, 28 top-level sections [Counted, High]) includes a section titled "Findings from the FrankenSuite source inspection" — the design *begins* by applying the sibling projects' lessons before any code is written [Code-verified, Medium]. And the license rider that excludes OpenAI and Anthropic sits in a repository whose CI workflows and revision receipts are built for agent execution (`AGENTS.md` section 8.1 dictates how crates are created "so it breaks every cargo command for every agent in the checkout, immediately") — a design corpus written *for* machine agents whose two named labs' agents may not use, benchmark, test, or analyze it (other labs' agents are not barred) [Inference, Medium — the tension is real; the framing is the packet's own].

---

## Franken-worthy next steps

1. **Run the pin through the maintainer's own verification lanes and publish the receipts.** The repo's `scripts/verify.sh fast` discipline (fmt, check, strict clippy, tests) and the remote-RCH receipt pattern from September 8 give a falsifiable bar. *Done when:* a retained remote-executed run of `./scripts/verify.sh fast` at the pin passes with the exact source-hash receipt, or the failure log is published. [Inference, High — process proposal, falsifiable]
2. **Qualify the first end-to-end media loop: Xvfb capture → software HEVC encode → fragment repair → decode → present, on one Linux host, localhost QUIC.** The slices exist (media workers, repair coverage, localhost QUIC tests); the loop is unassembled. *Done when:* a single machine runs the loop with measured end-to-end latency and a freshness-contract verdict (pass/fail) against the plan's targets. [Inference, High]
3. **Publish the unsafe-inventory census.** `fr-native` has 40 files with `unsafe` blocks and `fr-ffi` has 2; no per-site justification census exists the way FrankenRedis's 61-site census does. *Done when:* a per-site table (file, line, safety argument, owning OS API) is checked in and enforced by a count check. [Inference, High]
4. **Resolve the CI greenness gap at a new pin.** Recent `rust-verification.yml` runs failed at earlier SHAs; the pin has no registered check-runs. *Done when:* a completed CI run at a new pin is green on `rust-verification.yml` or its failure is root-caused in IMPLEMENTATION_STATUS.md. [Inference, High]
5. **Publish the first live Tailscale admission test against the plan's threat model (§19):** a same-tailnet peer admission with stale-metadata and shared-in-node cases. *Done when:* the TAILNET_ADMISSION.md threat cases have passing integration tests or are marked unqualified. [Inference, Medium]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** Remote desktop tools accumulate the wrong things — their own accounts, pairing databases, relays, and identity systems layered on top of a network that already has those; television-shaped video defaults (cinematic rate control, frame-count vanity metrics, multi-second hidden buffers) applied to terminal text and document work; and input paths that happily replay stale clicks into a desktop that has moved on. The result "feels slow in ways nobody can explain, and stops in ways nobody can trust" [Maintainer claim, Medium — README TL;DR, lightly paraphrased].

**Who feels the pain:** anyone who has tried to do serious work over a remote desktop and hit invisible latency — the maintainer's target is terminal-text/document workloads where freshness dominates throughput [Inference, Medium].

**Why now:** three maturities the design bets on: (1) Tailscale's tailnet identity as a solved problem the product can inherit instead of re-implementing (machine identity, HTTPS certs, admission evidence) [Maintainer claim, Medium]; (2) Rust async runtimes and QUIC/HTTP3 stacks mature enough to build a bounded-latency media pipeline [Inference, Medium]; (3) hardware HEVC on every platform (VideoToolbox, NVENC/QuickSync, MediaCodec) making a single-codec strategy viable [Maintainer claim, Medium — the plan's HEVC-only thesis, §8].

**Why this architecture, not a fork of RustDesk/Apache Guacamole:** stated in the plan's "What can genuinely distinguish this project" and the engineering thesis — the bet is that owning *less* (no identity system, no pairing store, no relay, no cinematic video pipeline) is the differentiator, and that the connective discipline (freshness contracts, expiring input authority, bounded queues) is a re-derivable layer rather than a product rewrite [Maintainer claim, Medium]. The incumbent comparison in §4.6 tests whether "owning less" is a moat or an abdication.

**Demand-side check (2026-09-22):** a web search for independent coverage of FrankenRemote (production users, third-party reviews, downstream forks, press) returned nothing beyond the repository and its 8 stars / 3 forks [External, High within recall caveats]. The installed base the design would *inherit* is real: Tailscale reports (via 2025 press) over 10,000 business customers and hundreds of thousands of individual users, with secondary sources citing 500,000+ weekly active users [External, Medium — press figures, not Tailscale's own audited numbers]. That is the addressable inheritance — every one of those tailnets is a network where FrankenRemote's "no account, no pairing" pitch is already true. But inheritance is not demand: none of those users has asked for a tailnet-native desktop, Tailscale SSH already covers the terminal case, and the conversion from "runs Tailscale" to "runs an unreleased third-party desktop on my tailnet" is the entire unproven step [Inference, Medium]. The plan's own threat model (§19) and the per-slice verification discipline are the demand evidence the repo offers: the maintainer treats the design corpus itself as the artifact that must convince, because there are no users yet [Inference, Medium].

**The honest-status contradiction to hold:** the brief for this packet called the repo "spec-first / pre-implementation," but the assessed tree contains 249,372 Rust lines, 236 passing tests at an earlier revision, and real X11/QUIC integration slices [Counted, High on the counts]. The README's own phrase is "early implementation; not an installable remote desktop yet" [Maintainer claim, High]. The packet treats the brief's characterization as **stale** and the README's as the working fact: this is an early implementation of a very large design, not a pure plan [Inference, High].

---

## 4.2 What it is — repo TL;DR

A 13-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) implementing the early Rust slices of a Tailscale-native remote workstation: `fr-core` (authority/policy), `fr-wire` (protocol codecs), `fr-media` (bounded media delivery with fragment repair), `fr-native` (platform adapters, X11 pointer/button path), `frd` (the daemon, largest at 97,033 lines [Counted, High]), `fr-client`, `fr-tailnet`, `fr-transport`, `fr-files`, `fr-e2e`, `fr-ffi`, `fr-lab`, `fr-web`. The plan targets 194,000 handwritten lines with a hard ceiling below 250,000; the tree already carries 249,372 counted Rust lines — the ceiling is effectively hit before any complete application exists [Code-verified + Maintainer claim, High].

One-line verdict: **the most elaborately specified remote-desktop design in the FrankenSuite — 1,439 plan lines, ~96 root design documents, 106 tracked design beads — with real implemented policy slices and executed test evidence, no complete application, and a self-imposed honesty discipline that forbids mistaking the slices for a product** [Inference, Medium].

---

## 4.3 Repo facts (claim inventory)

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 13 workspace crates (crates/* glob), 742 `.rs` files, 249,372 first-party Rust lines | demonstrated | Fresh clone; `Cargo.toml` members enumerated; per-crate line counts | [Counted, High] |
| 2 | Design plan v1.4: 1,439 lines, 28 top-level sections (122 headers incl. subsections), "researched design, not an implementation or benchmark report" | demonstrated | `wc -l` + `grep -c '^## '`; plan header read verbatim | [Code-verified, High] |
| 3 | "Not an installable remote desktop yet" — no complete `frd`/`fr` application, no qualified live transport, no hardware-qualified capture/codec path | demonstrated (the honesty claim, as a negative) | README status banner + IMPLEMENTATION_STATUS.md, read at pin | [Maintainer claim, High] |
| 4 | 236 tests passed, zero failed (Sept 8 RCH remote execution at revision 3307d19), plus check/clippy/fmt/docs gates green | partially demonstrated | Documented in IMPLEMENTATION_STATUS.md with exact commands, worker, and file-hash receipts — but not independently re-run by this packet; predates the pin | [Maintainer claim, High] |
| 25 | The four verification runs the docs cite are independently confirmed green: run 34231571592 (README's retained run at `e7d57d5a`), 34314791348 (tailnet admission), 34315921329 (admission integration), 34318181209 (input admission) — all `success`/`completed` | demonstrated (greenness of cited runs, not of the pin) | GitHub Actions API, checked 2026-09-22 | [CI-observed, High] |
| 26 | Real-QUIC software-HEVC X11 round-trip scenarios: X11 capture → software HEVC → real UDP/TLS QUIC → reassembly → supervised decode → X11 readback, with selective repair under forced backpressure (CHANGELOG "Native HEVC over primary Asupersync QUIC") | partially demonstrated | CHANGELOG entry + cited passing scenarios; not re-executed here; still not a qualified live transport per README | [Maintainer claim, Medium] |
| 5 | Real QUIC/TLS integration tests: control-lease renewal over real localhost UDP/TLS; observation renewal with QUIC control streams | partially demonstrated | CHANGELOG 2026-09-09/2026-09-10 entries with test descriptions and scope limits; not re-executed here | [Maintainer claim, Medium] |
| 6 | X11 pointer/button injection exercised against real X11/XTest servers (not headless mocks) | partially demonstrated | README input section; INPUT docs. Native keyboard/text, watchdog, live join unfinished | [Maintainer claim, Medium] |
| 7 | Media fragment repair: all nonempty 8-fragment loss patterns with 1–4 repair ranges, deterministic round trips | partially demonstrated | README + fr-media tests described; fake-backend media contracts only | [Maintainer claim, Medium] |
| 8 | asupersync is the sole async runtime, consumed as published 0.5.0 from crates.io (never a mutable sibling checkout) | demonstrated | Root Cargo.toml comment block + Cargo.lock (name="asupersync", version="0.5.0", source=crates.io) | [Code-verified, High] |
| 9 | `unsafe_code = "forbid"` workspace-wide; unsafe confined to `fr-native` (40 files) and `fr-ffi` (2 files) | demonstrated | Root lint table + per-crate unsafe-block file counts; named FFI boundary crates are the declared opt-outs | [Code-verified, High] |
| 10 | Zero `unimplemented!`/`todo!` sites across the workspace | demonstrated | `rg` over crates at pin | [Counted, High] |
| 11 | CI: 36 workflows (per-slice verify workflows + rust-verification, docs-integrity, native-integration-inputs, source-maintenance) | demonstrated | `.github/workflows` listing at pin | [Counted, High] |
| 12 | Greenness at the pin: unestablished — zero check-runs registered for fdeb7a2; the four most recent rust-verification runs (on commits pushed before the pin, by run timestamps) failed | demonstrated (as a negative finding) | GitHub API: commit check-runs (0) + workflow runs page, 2026-09-22 | [CI-observed, Medium] |
| 13 | 8 stars, 3 forks, 0 releases, no tags on the assessed tree | demonstrated | GitHub API, 2026-09-22 | [External, High] |
| 14 | 106 tracked design beads in `.beads/issues.jsonl` | demonstrated | Line count at pin | [Counted, High] |
| 15 | ~96 root-level design docs (`*.md` at root) recording per-slice design + verification scope | demonstrated | Root listing at pin (96 md files) | [Counted, High] |
| 16 | License: MIT with OpenAI/Anthropic rider; Restricted Parties include affiliates and anyone acting for them; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |
| 17 | HEVC-only video thesis (one video format, several hardware implementations), plan §8 | aspirational | Plan §8; no hardware-qualified codec path exists per README | [Maintainer claim, Medium] |
| 18 | Mobile plan: first-class native Swift/Kotlin apps explicit in v1.4; `mobile/` carries a real early slice — 38 files, ~1,382 Kotlin lines (Android: machine picker, session viewer, lifecycle) and ~1,939 Swift lines (iOS app + kit) | demonstrated (existence of an early native slice; no qualification claimed) | Plan v1.4 header; `mobile/` tree + line counts at pin | [Code-verified, High] |
| 19 | WebTransport browser client qualified (Chrome 153 scenarios passed, `results/latest/result.json`, 2026-09-20) | partially demonstrated | Retained result.json with passing handshake/datagram/origin-rejection scenarios | [Maintainer claim, Medium] |
| 20 | README disavowal: "Every latency target, operating envelope, and platform claim below is a proposed engineering objective from that plan, not a measured FrankenRemote result" | demonstrated | README banner read verbatim at pin | [Maintainer claim, High] |
| 21 | README structural drift: the "Develop and verify" section (L26) and "Proposed workspace" (L175) both say the current members are 6 crates (`fr-core`, `fr-wire`, `fr-media`, `fr-native`, `frd`, `fr-lab`); the workspace has 13 | demonstrated (README is stale on structure while honest on status) | README L26, L175 vs `Cargo.toml` glob (13 dirs) at pin | [Code-verified, High] |
| 22 | README ghost entries: the proposed-workspace tree lists `fr-platform/`, the `fr/` CLI, `xtask/`, and `web/` — none exists at the pin (`fr-native` occupies the `fr-platform` role) | demonstrated | README L180–191 vs root listing at pin | [Code-verified, High] |
| 23 | README verification evidence is behind IMPLEMENTATION_STATUS.md: README cites 76 tests at `e7d57d5`; the status doc records 236 tests at `3307d19` (2026-09-08) | demonstrated | README L37 vs IMPLEMENTATION_STATUS.md at pin | [Code-verified, High] |
| 24 | Partial media-boundary qualification: a trimmed FFmpeg 7.1.5 build (HEVC decoder only, no encoders/hwaccels/demuxers) was built by recipe `native/build_ffmpeg.py` with a retained evidence JSON (builder, platform, configure log) | partially demonstrated (build evidence retained; not independently re-run) | `native/ffmpeg-7.1.5-linux-x86_64.evidence.json` read at pin | [Code-verified, Medium] |

**What the inventory says in aggregate:** claims about *process and structure* (crate counts, plan contents, unsafe confinement, asupersync pinning, CI inventory) verify at High confidence; claims about *executed behavior* (test counts, QUIC/X11/media slices) rest on the maintainer's documented receipts — detailed, dated, and scoped, and now partially corroborated: the four verification runs the docs cite are independently confirmed green via the Actions API (claim 25) [CI-observed, High]. The corroboration covers the *cited* revisions, not the pin — greenness at the pin remains unestablished. Claims about *outcomes* (latency targets, HEVC hardware, mobile apps) are explicitly disavowed as proposals by the maintainer's own banner. **The drift pattern (claims 21–23) is the packet's sharpest governance finding:** the README is scrupulously honest about *status* ("not an installable remote desktop yet") while being stale about *structure* (crate count, directory tree, test totals) — the same crate-count-drift signature FrankenRedis showed, in a project whose pitch is auditability.

---

## 4.4 Codebase tour

**Workspace topology (13 members, [Counted, High]):** `fr-core`, `fr-wire`, `fr-media`, `fr-native`, `frd`, `fr-client`, `fr-tailnet`, `fr-transport`, `fr-files`, `fr-e2e`, `fr-ffi`, `fr-lab`, `fr-web`.

**Per-crate sizes (`.rs` lines, [Counted, High]):** `frd` 97,033 (269 files — the daemon and its process-role family, by far the largest); `fr-native` 44,167 (132 files — platform adapters); `fr-media` 21,718 (66 files); `fr-client` 19,098 (68 files); `fr-wire` 17,678 (59 files); `fr-core` 11,742 (29 files); `fr-transport` 10,069 (26 files); `fr-files` 8,762 (23 files); `fr-tailnet` 7,081 (19 files); `fr-lab` 6,071 (13 files); `fr-e2e` 3,750 (12 files); `fr-ffi` 1,255 (11 files); `fr-web` 948 (3 files). Total 249,372 / 742 files.

**Inside `frd` (the 97k-line daemon):** the source tree is organized as a process-role family, not a monolith: `broker/` (session brokering), `input_agent/` + `input_watchdog.rs` (the canonical input owner and its independent watchdog), `media/` + `media_quic/` + `media_egress.rs` (media pipeline and QUIC transport), `input_quic/` + `clipboard_quic/` (control-plane channels), `native_connection/` (platform connection), `session_agent/` + `session_startup/` (session lifecycle), `worker/` (supervised media workers), `host_policy/` (host-side policy), `service_install/` (installer), plus `linux/` and `windows/` platform subtrees [Code-verified, Medium — directory listing at pin; internal behavior not audited]. This is the plan's §5 "process boundaries" made concrete in the tree layout: crash isolation between media workers and the authority-owning broker is structural, not aspirational [Inference, Medium].

**Dependency posture:** asupersync 0.5.0 is the declared *sole async runtime* (root Cargo.toml: "The sole async runtime (AGENTS.md section 3.1). Pinned here so every consumer inherits one version") and resolves from the crates.io registry — the FrankenSuite sibling is consumed as an immutable published artifact, with an explicit prohibition on the mutable sibling checkout [Code-verified, High]. AGENTS.md corroborates: "Asupersync is the sole async runtime. No Tokio, async-std, smol, or any dependency that drags an alternate runtime into production" [Code-verified, High]. The lockfile contains no tokio, quinn, or mio — QUIC/TLS arrives via asupersync's own dependency tree (aes-gcm, chacha20poly1305, …), which concentrates the entire transport/crypto supply chain in one external crate [Code-verified, High]. Seven workspace crates depend on asupersync (frd, fr-tailnet, fr-files, fr-e2e, fr-lab, fr-transport, fr-native); only fr-tailnet and fr-transport enable its `tls` feature — the TLS/QUIC surface is opt-in per crate, not ambient [Code-verified, High]. The workspace sets `unsafe_code = "forbid"` in `[workspace.lints.rust]`; the named FFI boundary crates (`fr-ffi`, platform adapters in `fr-native`) are the documented opt-outs [Code-verified, High].

**Data flow, as reconstructed (README/plan claims checked against crate presence, not executed):**

- **Admission — `fr-tailnet` → `frd`:** Tailscale identity, admission evidence, and HTTPS certificates are inherited from the installed Tailscale client; no FrankenRemote credential store exists [Maintainer claim, High]. The plan's threat model (§19) treats tailnet membership inference, shared-in nodes, external sharees, and forged `100.x` sources as first-class attack surface — SECURITY.md mirrors this verbatim [Code-verified, High].
- **Authority — `fr-core` → `frd`:** one serialized authority owner per remote session; tickets, challenges, control leases, and generation fencing; input receipts joined to submission-time checks with the `InputResult` (0x0048) codec in `fr-wire` (file `crates/fr-wire/src/input_result.rs` verified to exist at the pin [Code-verified, High]; behavior not executed) [Maintainer claim, Medium].
- **Input — `frd` → `fr-native` → OS:** pointer/button injection against real X11/XTest servers; native keyboard/text and the independent input-agent watchdog unfinished [Maintainer claim, Medium]. An independent input agent watches the input owner; lease expiry and release-only cleanup are fenced [Maintainer claim, Medium].
- **Media — capture → `fr-media` → `fr-transport` → decoder:** bounded queues at every stage; fragment-level selective repair with coalesced ranges; "a complete independent picture supersedes older queued media" as the anti-buffering rule [Maintainer claim, Medium]. The transport/QUIC spike work (`spikes/quic-native`, `MEDIA_QUIC.md`) is not the qualified path [Maintainer claim, High].
- **Presentation — `fr-native` workers:** supervised Linux media workers; the plan demands seccomp-BPF sandboxing for the Linux software decoder with automated escape-attempt tests (`crates/fr-native/tests/decoder_sandbox_escape.rs` — existence verified at pin [Code-verified, Medium]); residual trust in GPU drivers explicitly disclosed [Maintainer claim, Medium].
- **Lab — `fr-lab`:** the deterministic lab inherited from asupersync's design vocabulary (cancellation-aware ownership, bounded channels), reused as the testing discipline [Maintainer claim, Medium].

**Notable structural facts:** zero `unimplemented!`/`todo!` sites [Counted, High] — slices are written to completion or not written, a discipline that makes the honesty claims auditable; the plan budgets 194k Rust lines with a 240k planned maximum and a hard stop below 250k (plus a separate ≤20k allowance for JS/Swift/Kotlin/build glue, README L193) — the tree already carries 249,372 counted Rust lines, i.e. 99.7% of the hard stop before any complete application exists, so the "fixed counting command" discipline (`./scripts/verify.sh count`) is about to be tested against its own ceiling [Counted + Maintainer claim, High]; `mobile/` carries a real early native slice (38 files, ~1.4k Kotlin + ~1.9k Swift lines — claim 18), not stubs; `native/` retains a trimmed-FFmpeg build recipe with qualification evidence (claim 24).

---

## 4.5 The maintainer's stated case

**The pitch, in the maintainer's own structure:**

1. **Own less, connect better.** Tailscale owns connectivity/identity; asupersync owns async lifetimes; platform APIs and existing codecs own capture and HEVC. FrankenRemote owns only the policy glue: freshness contracts, expiring input authority, bounded queues, diagnostics that answer "why does this feel slow?" [Maintainer claim, Medium].
2. **Freshness over throughput.** Bounded queues at every pipeline stage; obsolete queued media is superseded rather than delivered late; loss recovery is codec-aware [Maintainer claim, Medium — design claims with fake-backend contract tests, not live measurements].
3. **Input authority that ends cleanly.** Leases, tickets, generation fencing, submission-time rechecks, held-key cleanup; an authority that expires instead of accumulating [Maintainer claim, Medium — tested slices per IMPLEMENTATION_STATUS.md].
4. **Spec-first engineering as a product in itself.** A 1,439-line v1.4 plan, per-slice design docs, 106 tracked beads, 36 CI workflows, and verification receipts retained as evidence — the discipline is the deliverable until the product exists [Maintainer claim, High].

**The disavowal — quoted and located precisely:** the README status banner, immediately below the title block: *"Every latency target, operating envelope, and platform claim below is a proposed engineering objective from that plan, not a measured FrankenRemote result."* IMPLEMENTATION_STATUS.md (updated 2026-09-08) adds: *"No application or live-transport/hardware phase gate is declared complete by the tests below"* and *"UBS, Miri, fuzz-engine campaigns, macOS/Windows native builds, browser/mobile execution, live Tailscale/QUIC/H3, hardware capture/HEVC, and installer/rollback qualification were not run in this implementation pass"* [all Maintainer claim, High].

**Benchmark and conformance audit:** there are no latency or throughput numbers to audit — and that is the maintainer's explicit choice. The only quantitative "results" are test counts (236 remote-executed at an earlier revision [Maintainer claim, High]), contract-test scenarios (WebTransport browser scenarios passed 2026-09-20 [Maintainer claim, Medium]), and UBS scan output that was nonzero (26 critical, 282 warnings, classified by self-review as misidentified/binary-decoded sites — "the scan remains nonzero, not a clean full-lane pass" [Maintainer claim, High]). **No maintainer number is cited as a performance result anywhere; this is the cleanest benchmark posture in the FrankenSuite — there is nothing to disavow because nothing was claimed** [Inference, Medium — the comparison is the packet's judgment over the assessed packets so far]. Reproduction cost: the `fast` lane requires the pinned `nightly-2026-08-31` toolchain and FFmpeg 7:8.0.1; the `full` lane requires UBS; the `release` lane is intentionally blocked [Maintainer claim, Medium].

---

## 4.6 Competitors

The incumbent remote-desktop vendors win on installed base, platform breadth, and managed infrastructure; FrankenRemote's uncontested edge is its *design corpus* — nobody else publishes the policy layer (freshness contracts, input-authority semantics, tailnet threat model) as a standalone artifact with per-slice verification receipts [Inference, Medium].

- **RustDesk (Rust, self-hosted):** the closest ideological neighbor — open-source, no-account self-hosting via your own relay infrastructure: `hbbs` (ID/rendezvous/signaling) plus `hbbr` (relay fallback when hole-punching fails), documented in [RustDesk's self-host docs](https://github.com/rustdesk/doc.rustdesk.com/blob/HEAD/content/self-host/_index.en.md) [External, High]. It wins the "no vendor account" lane today with real users and releases. The architectural contrast is exact: RustDesk re-implements rendezvous + relay (the infrastructure FrankenRemote refuses to build), while FrankenRemote inherits identity from the tailnet — "own less" vs. "own the control plane" [Inference, Medium]. RustDesk's video pipeline is FFmpeg-driven with hardware acceleration (NVENC/VA-API/QuickSync/VideoToolbox) [External, Medium]; whether it accumulates the hidden buffers FrankenRemote's freshness contract attacks is untested here [Inference, Low].
- **Tailscale's own solutions (Tailscale SSH / Serve / app connectors):** Tailscale owns the identity/connectivity layer FrankenRemote inherits; Tailscale SSH already solves remote *terminal* access over the tailnet with ACLs and session recording [External, High]. FrankenRemote's answer is the graphical desktop — a lane Tailscale itself has not built, and the design bets the tailnet vendor never will [Inference, Medium]. This is the highest-risk dependency in the packet: the platform owner could occupy the lane (see the kill test, Q8).
- **Apache Guacamole (clientless gateway):** owns the browser-as-client, no-install lane with real enterprise deployments [External, High]. FrankenRemote's WebTransport browser work (Chrome 153 scenarios passing [Maintainer claim, Medium]) gestures at this lane but is years behind [Inference, Medium].
- **Moonlight/Sunshine (game-streaming lineage):** the best existing implementation of "freshness over throughput" — low-latency HEVC streaming over a local network with hardware encode/decode [External, High]. It owns the low-latency-video lane but requires NVIDIA GPUs on the host and has no desktop-authority model (no input leases, no approval, no tailnet identity) [Inference, Medium]. FrankenRemote's thesis is that the gaming streamers solved video but not *workstation* semantics; the input-authority machinery is the claimed differentiator [Inference, Medium]. Note the narrowing: the repo's real-QUIC software-HEVC X11 round-trip scenarios (claim 26) are a first step onto Moonlight's turf — but software encode and X11 readback are not hardware NVENC, and no latency numbers exist to compare [Inference, Medium].
- **AnyDesk / TeamViewer / Parsec:** own the commercial ease-of-use lane with massive installed bases and relay infrastructure [External, High]. FrankenRemote's "no relay, no account" stance is a direct rejection of their business model — which is also their distribution advantage [Inference, Medium].
- **VNC/RDP (the protocols):** commodity, free, built into every OS. The "good enough" floor [External, High].
- **Unoccupied lane:** a tailnet-identity-native remote workstation with a published freshness contract, expiring input authority, and a tailnet threat model has no direct occupant — RustDesk does not do tailnet identity; Tailscale does not do desktops; Moonlight does not do input authority [Inference, Medium]. Whether the lane is unoccupied because it is hard or because buyers will not pay for it is the unproven bet the whole project rests on [Inference, Medium].

---

## 4.7 Skeptic's take

*Weaknesses are numbered 1–8 below; elsewhere "§4.7.N" means weakness N.*

1. **[FATAL] There is no product.** 249,372 lines, 36 CI workflows, 236 passing tests at an earlier revision — and no complete application, no qualified live transport, no hardware-qualified codec path, no release, no users [Maintainer claim + Code-verified, High]. Every downstream claim about the design's ideas rests on slices, not on a system that has ever opened a machine on a tailnet. The design corpus is the deliverable, and a design corpus is not a workstation.
2. **[HIGH] The line budget is already exhausted.** The plan's hard stop is below 250,000 handwritten Rust lines (plus ≤20k glue allowance); the tree carries 249,372 counted Rust lines [Code-verified, High] before any end-to-end loop exists. Either the budget discipline was a fiction, or the remaining work (live transport, hardware capture, macOS/Windows adapters, installer) must be built in ~600 lines — impossible — which means the ceiling will be revised or abandoned. A budget that dies before the product ships was never a budget [Inference, Medium].
3. **[HIGH] CI is red near the pin and green at the pin is unestablished.** The four most recent `rust-verification.yml` runs observed 2026-09-22 failed (all on commits pushed before the pin, by run timestamps) [CI-observed, Medium]; the pin itself has zero registered check-runs [CI-observed, Medium]. A project whose verification discipline is its headline asset cannot afford red CI on the eve of assessment.
4. **[MEDIUM] Bus factor 1 with a 1,439-line plan.** One human maintainer (Jeffrey Emanuel), 8 stars, 3 forks [External, High]. The design corpus is written for agents ("every agent in the checkout" — root Cargo.toml), but the license rider bars the two labs most likely to supply agent evaluation from touching it (§4.8). The corpus's intended audience and its permitted audience do not overlap.
5. **[MEDIUM] The "own less" thesis is an abdication risk.** Inheriting Tailscale identity, asupersync's runtime, platform capture, and FFmpeg means the product's quality ceiling is set by four external parties' roadmaps. If Tailscale changes LocalAPI, if asupersync's 0.5.0 API churns, if a platform deprecates a capture API, FrankenRemote absorbs the breakage with no leverage [Inference, Medium]. Owning less is cheaper until the landlord renovates.
6. **[MEDIUM] Zero `unimplemented!` sites is suspicious, not reassuring.** 249k lines with no `todo!`/`unimplemented!` against a design that admits most integration boundaries are unqualified suggests the code is written *as if* complete in slices whose seams are untested. The honesty docs name the gaps; the code's completeness posture does not [Inference, Medium].
7. **[LOW] The UBS scan was nonzero and self-classified.** 26 critical / 282 warnings, classified by self-review as misidentifications — "Independent review has been requested but has not returned" [Maintainer claim, High]. The maintainer disclosed this; the classification is still the fox guarding the henhouse until the independent review lands [Inference, Medium].

8. **[MEDIUM] The README drifts on structure while preaching auditability.** Claims 21–23: two sections say the workspace has 6 crates (it has 13), the proposed tree lists `fr-platform/`, an `fr/` CLI, `xtask/`, and `web/` (none exists), and the cited test total (76) trails the status doc (236) by a month. The README is honest about *status* and stale about *structure* — the exact crate-count-drift signature FrankenRedis showed, and a worse look here because the project's pitch *is* auditability [Code-verified, High on the facts; the severity is Inference, Medium].

**Bear-case steelman (strongest counter-case):** FrankenRemote is a 250k-line design document with a test suite — the most elaborate remote-desktop plan ever published, and no remote desktop. The line budget is exhausted before the product exists; the CI was red at every recent SHA and the pin has no check-runs; there are no users, no releases, and 8 stars. The "own less" architecture means Tailscale could ship a native desktop client and erase the lane in a quarter, or simply change an API the design depends on. The license rider forbids the best-equipped evaluators from analyzing it. The rational market response is to read the plan's policy chapters (freshness contracts, input-authority semantics) as design literature and never run the code. Its most likely end state is a frozen monument: the definitive unbuilt remote workstation [Inference, Medium — deliberately uncharitable; the counter-evidence is the executed slice evidence and the honesty discipline, which are real but slice-scoped].

---

## 4.8 Maintenance & succession

**Bus factor: 1.** One human maintainer (Jeffrey Emanuel); copyright in LICENSE names him; 8 stars / 3 forks [External + Git-observed, High]. No succession plan, no second committer, no foundation [Inference, Medium — absence of evidence across assessed materials]. No release artifact exists to fork from cleanly [External, High]. If the maintainer stops, the project freezes at whatever commit the stop happens on [Inference, High].

**Governance velocity:** pushed today (2026-09-22); CHANGELOG shows dated entries 2026-09-08/09/10 — active within the last two weeks [Git-observed + Maintainer claim, High]. The beads system (106 tracked design/implementation beads) and the per-slice CI workflows are the governance machinery; they are maintainer-operated, not institutional [Inference, Medium].

**License — read verbatim, classified honestly.** LICENSE at the pin: "MIT License (with OpenAI/Anthropic Rider)", SPDX `LicenseRef-MIT-OpenAI-Anthropic-Rider` [Code-verified, High]. The rider defines "Restricted Parties" as "OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative)" — and "Affiliate" as >50% voting control or the power to direct management [Code-verified, High]. **Exact scope of the exclusion:** "no rights are granted to any Restricted Party"; the "use" definition expressly includes "copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems"; breach "automatically and immediately terminates" the license [Code-verified, High]. **OSI status: non-OSI.** The rider denies use to named parties — a field-of-use/personal restriction incompatible with the Open Source Definition's non-discrimination clauses [Inference, High — the classification is a legal judgment, but the incompatibility is mechanical]. **As strategy (§6 lens):** the exclusion bars the two AI labs from *evaluating* the work (benchmarking, testing, analyzing are all named), which sabotages the stated mission of rigorous machine-assisted engineering — the corpus is written for agents (AGENTS.md, agent-execution receipts) while excluding the two labs whose agents would most plausibly review it [Inference, Medium]. The rider does not exclude ordinary users, enterprises, or other AI labs — but it poisons exactly the evaluation channel the project most needs.

**Agent co-authorship:** not measured in this packet (no commit-history deepening was performed) — listed as an open question in §4.12 [Inference, Low].

---

## 4.9 NODUS factsheet

| Criterion | Score | Justification (one line) |
|---|---|---|
| Technology readiness | TRL 3–4 | Experimental proof of concept: tested policy/media/input slices with executed test evidence; no integrated system, no operational environment |
| Strategic relevance | 3/5 | Freshness-contract and input-authority policy is genuinely novel infrastructure thinking for remote workstations |
| Impact potential | 3/5 | If the design lands, it redefines what "remote desktop" means; design-stage, so the ceiling is speculative |
| Implementation feasibility | 2/5 | 249k lines with no end-to-end loop, exhausted line budget, red CI near the pin — the path from slices to product is the risk |
| Time to mainstream | 2/5 | No release, no users, no qualified hardware path; years out even in the upside case |
| Collaboration potential | 2/5 | The rider bars two major AI labs from analysis; bus factor 1; but the design corpus is readable by everyone else |

**Ring: Explore** [Inference, Medium]. The Rulebook assigns Monitor to plan-stage work and Explore as the default for substantive-but-unproven. FrankenRemote is beyond a pure plan — it has executed test evidence on implemented slices (remote-executed 236-test gates with receipts, real QUIC/TLS and X11 integration tests, deterministic media-repair coverage) — which is what "substantive" means here. Ring-down discipline ("when in doubt, ring down") was considered; the packet is not in doubt because the executed evidence is documented with exact commands, workers, and file-hash receipts. The ring is explicitly fragile: if the slice evidence turns out to be receipt-theater (unreproducible), the correct ring is Monitor.

---

## 4.10 Wardley placement

- **Commodity surface:** Tailscale identity/connectivity, QUIC/HTTP3, HEVC hardware codecs, platform capture APIs — commodity/product stage, rented not built [Inference, High].
- **Custom-built reimplementation:** the wire protocol, freshness-contract media pipeline, input-authority machinery — custom-built, genesis-to-custom transition; nothing here is commodity because the design *defines* the policy layer [Inference, Medium].
- **Genesis-stage novel elements:** the freshness contract as a formal discipline (bounded queues, supersede-obsolete-media rules), expiring input authority with submission-time receipts, and the per-slice verification-receipt culture itself — genesis, and the most likely methodology export (§lens 2) [Inference, Medium].

**What would move each:** the commodity surface moves only with vendor roadmaps — Tailscale shipping a native desktop client would move the *whole map* by collapsing the unoccupied lane (the kill test, Q8); the custom layer moves from custom-built to product with the first qualified end-to-end loop (revisit trigger 1) and to commodity only if a second implementation re-derives the same policy (which would validate the "policy is the product" thesis); the genesis elements move to practice when a second project — inside or outside the FrankenSuite — adopts the freshness-contract discipline or the verification-receipt pattern (the methodology-export lens). The directional risk is downward: if the end-to-end loop never assembles, the custom layer slides back into genesis-as-literature rather than forward into product.

---

## 4.11 Trajectory (12 / 24 / 60 months) **[Inference]**

**Base case:** the design corpus keeps growing, slices keep landing with receipts, and the end-to-end loop keeps not assembling — the project becomes the FrankenSuite's most cited design document and never a workstation. The line budget is formally revised or quietly abandoned; CI goes green at some pins and red at others; stars stay in the single digits.

**Upside bifurcation:** a first qualified end-to-end loop (Xvfb → software HEVC → repair → decode → present over localhost QUIC with measured latency) assembles within 12 months, demonstrating the freshness contract against the plan's targets; a live Tailscale admission test follows; the rider is narrowed or dropped, enabling institutional evaluation; a second maintainer arrives. Then: Explore → Pilot on a bounded real workload (the maintainer's own tailnet) by month 24.

**Decay:** velocity stops (the maintainer's attention is the single point of failure); the design docs drift from the code (the plan is already v1.4 — drift monitoring is the load-bearing habit); the repo freezes as a monument.

**Revisit triggers:** (1) first retained, reproducible end-to-end media loop with latency numbers; (2) first live Tailscale session test against the §19 threat model; (3) CI green at a new pin on `rust-verification.yml`; (4) a tagged release or second maintainer; (5) any license-rider change; (6) Tailscale shipping or announcing a native desktop product (the kill-test event).

---

## 4.12 Limitations and open questions

**Not done:** the workspace was never compiled; no test was executed; no benchmark was reproduced; no live Tailscale session was attempted; the 1,439-line plan was skimmed, not exhaustively read; per-file unsafe-site justification was not sampled; agent co-authorship was not measured (no history deepening); the beads DB beyond its count was not read; independent coverage was searched with recall caveats only; the `spikes/` directories and `native/` tree were not inventoried in depth.

**Open questions that would most change the verdict:**
1. Is the slice evidence reproducible — would `./scripts/verify.sh fast` pass at the pin on a fresh checkout? (Would confirm or collapse the Explore ring.)
2. What fraction of the 249k lines is load-bearing policy vs. scaffolding and duplication? (Bears on the exhausted line budget.)
3. What share of commits carry agent co-authorship trailers, and do the named Restricted Parties' models appear? (Bears on the rider's internal coherence.)
4. Has any second party — human or agent — ever executed the verification lanes independently? (Bears on whether the receipts are validation or theater.)
5. What is the actual asupersync 0.5.0 API surface used, and is it stable enough to build a product on? (Partially answered in v4: 7 crates depend on it; only fr-tailnet and fr-transport enable the `tls` feature. Remaining: whether the 0.5.0 API is stable across the sibling's own releases.)

---

## The eight deepening questions (one paragraph each)

1. **Provenance.** The repository records provenance *of its own construction*: IMPLEMENTATION_STATUS.md retains exact source commits, worker IDs (`hz3`), toolchain versions (`nightly-2026-08-31`), FFmpeg and Xvfb package versions, before/after tracked-file hashes, and detached-checkout RCH receipts for the September 8 gates [Maintainer claim, High]. What it does *not* record is provenance of artifacts at runtime — media frames, input receipts, and session decisions carry no attestation structure in the assessed slices; the `InputResult` (0x0048) codec records *outcomes* of input actions, not *who/what* produced them [Inference, Medium]. Making that portable would require the wire protocol to carry origin attestations (session key identity, authority generation, submission-time binding) as first-class signed fields — the plan's authority machinery has the hooks (tickets, generations, receipts) but no attestation format is specified [Inference, Medium].

2. **The embeddable unit.** The smallest adoptable piece is the freshness-contract discipline itself: bounded queues at every stage with the supersede-obsolete-media rule, implementable in any media pipeline without the repo's wire protocol [Inference, Medium]. Next-smallest is the input-authority pattern: expiring tickets, generation fencing, and submission-time receipt records — `fr-wire`'s codecs are allocation-free and dependency-light, so adopting the *protocol bytes* costs a codec port, not the runtime [Inference, Medium]. Adopting the code as-is costs the asupersync runtime, the Tailscale client, and the license rider — the rider is the real adoption cost, since any evaluation by the two named labs is unlicensable [Inference, High].

3. **Unexercised option value.** The architecture holds: a deterministic lab (`fr-lab`) inherited from the asupersync vocabulary that could run the entire session state machine as a reproducible simulation — currently used as test discipline, not as a design-exploration tool [Inference, Medium]; the fragment-repair machinery, built for media, could generalize to any unreliable datagram channel (file transfer, clipboard) — `fr-files` exists but the repair pattern's reuse there is unspecified [Inference, Low]; the per-slice verification-receipt culture (exact commands, hash receipts, retained logs) could be exported as a CI template for the whole FrankenSuite — currently repo-local [Inference, Medium]. What unlocks them is the same event: a working end-to-end loop that gives the machinery something to observe.

4. **Benchmark honesty.** There are no performance numbers to audit — the README's banner disavows every latency target as a proposed objective, and the only quantitative results are test counts and a nonzero UBS scan [Maintainer claim, High]. This is the cleanest benchmark posture in the program: nothing load-bearing rests on an un-gated number, because no number is load-bearing. The load-bearing claims are instead *existence* claims (the slices exist and their tests passed), and those rest on maintainer-documented receipts that this packet did not independently re-run — that is the honesty gap that matters here, not benchmarks [Inference, High].

5. **The governance path.** The credible route from one maintainer to an institution runs through the design corpus, not the code: a university lab or a Tailscale-adjacent company adopts the *plan* (freshness contracts, input authority) as a research artifact, funds the end-to-end loop, and the rider is the first thing renegotiated [Inference, Medium]. What breaks first if velocity decays is the plan-to-code correspondence — the 1,439-line plan at v1.4 against a 249k-line tree is already a two-body problem, and drift between them is the decay signature to watch (the packet's ring hinges on the slices staying honest) [Inference, Medium].

6. **The license as strategy.** The rider excludes OpenAI, Anthropic, their >50%-controlled affiliates, and anyone acting for them — from *use*, expressly including benchmarking, testing, analyzing, indexing, and training-data incorporation; breach terminates automatically [Code-verified, High]. It serves the mission only under one reading: the maintainer believes AI labs would extract the design's value without contributing, and the rider is a toll booth [Inference, Medium]. It sabotages the mission under the stronger reading: the project's verification culture is built for machine agents (AGENTS.md, agent-execution receipts, 36 CI workflows), yet excludes the two labs whose models would most plausibly stress-test it — and "analyzing" arguably covers independent assessment itself, meaning the rider chills the exact scrutiny the project invites [Inference, Medium]. For a design-stage project with no users, excluding evaluators is cost without revenue.

7. **Agent-era fit.** The concrete agent workload that would pick this over RustDesk or Tailscale SSH is an autonomous operator that needs *graphical* access to a tailnet machine with auditable input semantics — e.g., a maintenance agent that must click through a GUI installer on a headless host and produce a receipt ledger of every injected action with submission-time checks [Inference, Medium]. What has to become true first: the end-to-end loop must exist, the input-agent watchdog must be finished, and the rider must not bar the agent's lab from running the code — all three are currently false [Inference, High].

8. **The kill test.** The single event that falsifies the core thesis is **Tailscale shipping a first-party graphical desktop client** — the thesis is that the tailnet vendor owns identity and will never own the workstation layer; a native Tailscale desktop (or a bundled partnership with an existing vendor) collapses the "unoccupied lane" (§4.6) and strands the 249k lines as a third-party reimplementation of a platform feature [Inference, Medium]. The experiment that falsifies the *engineering* claim is cheaper: assemble the first end-to-end loop and measure end-to-end latency against the plan's freshness targets — if bounded queues and supersede rules cannot beat a tuned Moonlight/Sunshine pipeline on identical hardware, the freshness contract is literature, not engineering [Inference, High].

---

## Cross-cutting lenses (mandatory)

- **The decoupling lens.** FrankenRemote is the *policy-from-infrastructure* decoupling: it argues that a remote workstation decomposes into commodity infrastructure (Tailscale identity, QUIC transport, platform capture, hardware codecs, the asupersync runtime) plus a thin policy layer (freshness, authority, bounded recovery) — and that the policy layer is the only part worth building [Inference, Medium]. This is the same "memory separating from the store" instinct the Redis deep-dive named, applied to remote access: identity separates from the application.
- **The methodology-export lens.** If the product fails, what survives is the verification-receipt discipline: per-slice design docs, exact-command retained receipts with source-hash binding, negative-space honesty ("not an installable remote desktop yet" in the README banner), and the beads-tracked design governance. That machinery is a candidate export to the FrankenSuite in its own right — and it is further along than the product [Inference, Medium].
- **The asupersync question.** Verified, not assumed: asupersync 0.5.0 is the declared *sole async runtime*, pinned in `[workspace.dependencies]` with `default-features = false` and a comment block mandating the published release ("never the mutable sibling checkout"); Cargo.lock resolves it from the crates.io registry [Code-verified, High]. The relationship is genuine dependency, not evaluation-and-rejection (contrast FrankenRedis). The risk is concentration: one external runtime owns all async lifetimes.
- **The rider question.** Quoted verbatim in §4.8: Restricted Parties = OpenAI, Anthropic, affiliates, and anyone acting for them; "use" includes benchmarking, testing, analyzing, indexing, training-data incorporation; breach = automatic termination [Code-verified, High]. As strategy it excludes exactly the evaluators a rigor-first project needs most — see Q6 and §4.8.

---

*End of packet. Final write after 5 grader rounds. Assessment date 2026-09-22.*