That last sentence is the whole product thesis. Every desktop agent harness — grok-build, Codex, Claude Code — assumes it can fork a process, read a broad filesystem, and keep a session alive for hours. On a phone, each of those assumptions is a store-rejection risk. PhoneBuddy is built around the prohibition instead of around Linux, and the interesting question is not whether its feature list is long. It is whether the architecture holds up, and whether the small project around it is ready for production. This review keeps those two questions separate, because the answers differ sharply.

What is the PhoneBuddy agent engine, exactly?

PhoneBuddySDK is a three-crate Rust workspace published by APUS AI Lab: phone-buddy (the agent engine), phone-buddy-ffi (the C ABI that exports phone_buddy.h), and phone-buddy-cli (a development CLI with mock, self-test, chat and generate subcommands). It requires Rust 1.94+, ships a static .a for iOS with a Swift wrapper and a .so for Android with Kotlin/JNI bindings, and is licensed Apache-2.0.

It is important to be precise about what it is not. PhoneBuddy is not a model, not an inference runtime, and not a cloud service. It carries no weights and performs no inference of its own. It is the orchestration layer — planning, tool dispatch, sandboxing, subagent fan-out, scheduling — that sits between a language model you supply and the phone your app lives on. If you are looking for something that runs a quantized 4B model on-device, this is the wrong repository; if you want the loop that decides which tool to call and in what order, this is precisely the right one.

The vendor is small and new. The GitHub organization was created on 2026-08-18, hosts four public repositories, and belongs to APUS AI Lab (apusai.com). The SDK itself has a short history: v0.1.1 and v0.1.2 released on 2026-08-18 and 2026-08-19, and v0.2.0 on 2026-08-25. Live metrics on 2026-10-01 read 36 stars, 13 forks, 1 open issue, 3 releases.

PhoneBuddy is two different projects — which one are you reading about?

This matters more than it sounds, because searching for “PhoneBuddy” mixes two unrelated things, and most coverage does not say which one it means.

The research line trains models to operate real phones, using a mock-app environment (PhoneWorld) plus real-app reinforcement learning. It is a legitimate and interesting project, but it answers a different question: “can a model learn to use a phone?” The SDK reviewed here answers “how do I run an agent loop inside an app that the App Store will not reject?” If a comparison article you read cites the 83.2% AndroidWorld figure as a property of the SDK, it has merged two projects that share nothing but a name.

Why does mobile break desktop agent architecture?

Because the thing every desktop harness depends on — spawning a child process — is the thing mobile stores are built to prevent.

Apple’s Guideline 2.5.2, verified verbatim on 2026-10-01, reads: “Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app,” with a narrow exception for educational code. In early 2026 that clause was enforced in a visible wave: Replit, Vibecode and similar build-on-phone tools were blocked from shipping updates under 2.5.2.

Google Play’s Device and Network Abuse policy is more surgical, and worth quoting in full because it is the friendlier of the two: “an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).” The same page adds that interpreted code “loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies.”

Read those two paragraphs together and the design space becomes obvious. A shell that forks /bin/bash is not merely risky on mobile — it is architecturally hostile to both policies. An interpreter that executes bounded scripts inside your own process is explicitly contemplated by Google and narrowly tolerated by Apple. PhoneBuddy chose the second shape for everything, including the shell.

Does the PhoneBuddy agent engine really spawn zero child processes?

Verified: yes. This is the claim the project rests on, and it survives an independent source check rather than a README read.

On 2026-10-01 the entire main branch was downloaded as a tarball (commit c2fc7ea687fcc347412d6697093cdcedab7d8d30, dated 2026-09-13, sha256 prefix d89a0f1899d3fafe). The archive contains 70 .rs files across 163 tracked paths. Grepping the full source returned:

• 0 occurrences of std::process::Command
• 0 occurrences of tokio::process
• 0 occurrences of Command::new
• no libc::fork, execv, execl, or posix_spawn

That is a static result, not a runtime proof, and it should be stated that way. But it is the right static result: the forbidden primitives are simply absent from the codebase, not merely discouraged by convention.

The upstream provenance explains how that is even possible. The repository’s NOTICE file states that the engine is derived from xAI’s grok-build — a mature Apache-2.0 coding-agent harness with 27,171 stars and 5,111 forks as of 2026-10-01 — and lists the modifications: std::process and tokio::process were replaced with pure-Rust BusyBox applets plus Boa, the TLS stack was swapped from tokio-rs to rustls/ring, and a C FFI layer with Swift and Kotlin wrappers was added.

That lineage cuts both ways. On one hand, the agent loop is not a weekend rewrite; it descends from a harness with 27k stars. On the other, desktop-shaped assumptions travel with the inheritance — context budget defaults, TUI-era tool naming, session semantics designed for a terminal — and a commercial embedder inherits a NOTICE attribution obligation it must satisfy in shipped binaries.

What replaces the shell, the filesystem and the subprocess?

Four in-process substitutions carry the architecture. Each maps a desktop primitive onto something a store reviewer will accept.

How does the virtual shell work without a real shell?

Instead of spawning /bin/sh, the engine implements a BusyBox-style shell in memory. Command parsing, builtins like ls, cat, grep and find, and the pipe semantics between them are executed by Rust code operating on an in-memory view of a sandboxed directory. There is no binary to execute and no operating-system process to create, so the classic “app downloads and runs a shell” narrative has no foothold. The observable behaviour looks familiar to a model that was trained on terminal transcripts, which matters: the tool descriptions still read like a shell to the LLM, so prompt compatibility is preserved without the primitive being real.

How is the file sandbox enforced?

File tools operate through a path-jailing layer that confines reads and writes to a designated directory inside the app container. Requests that try to traverse outside that root are rejected rather than normalized. Because the same layer sits under the virtual shell and the file tools, a model cannot escape the jail by switching interfaces. The audit reviewed below confirms path jailing as a static control.

What protects the embedded JavaScript sandbox?

Rather than pulling in a JS engine with network or filesystem reach, PhoneBuddy embeds boa_engine — a pure-Rust JavaScript interpreter — and bounds what scripts can do: no ambient filesystem access, no ambient network access, host functions must be explicitly exposed, and execution carries loop limits and timeouts. This is the piece that most needs the store-policy reading above, because an embedded interpreter is exactly what the Google Play carve-out contemplates and exactly what Apple’s DPCLA 3.3.2 treats narrowly.

Do subagents spawn anything?

No. Subagents are in-memory task contexts inside the same process, each with its own conversation state and tool permissions, coordinated by the parent loop rather than by an operating-system process boundary. Scheduled tasks follow the same pattern: cron-style timers inside the runtime, not system schedulers. Human-in-the-loop callbacks are host callbacks, not external job runners.

Apple Guideline 2.5.2 and DPCLA 3.3.2, read precisely

This is where the compliance argument actually stands or falls, and the honest version is more interesting than the marketing version.

Guideline 2.5.2 is about downloading or executing code that introduces or changes features. It is not a blanket ban on forking, and it is not a ban on interpreters as such. What it forbids is an app becoming an environment where functionality arrives after review. A pure-Rust agent loop that ships with the binary adds no post-review functionality, so the strongest part of PhoneBuddy’s position is that it never needs to argue about dynamic code delivery at all — there is nothing to deliver.

The embedded JavaScript engine is the sharper edge. Apple’s Developer Program License Agreement 3.3.2 permits interpreted code “run by the built-in WebKit framework or JavaScriptCore,” provided the scripts do not change the app’s primary purpose. A non-WebKit interpreter such as boa_engine is not covered by that sentence on its face. It may still be acceptable — the guideline’s operative test is whether the app’s purpose changes — but it is a position you argue with a reviewer, not a safe harbour you invoke.

One caveat on sourcing: the DPCLA wording above is quoted second-hand from AppCompliance’s analysis of the 2026 enforcement wave. A direct fetch of the agreement PDF returned HTML rather than the document on 2026-10-01, so treat the DPCLA quotation as a well-sourced secondary citation and the Guideline 2.5.2 quotation — taken directly from Apple’s guidelines page — as primary.

Google Play’s policy is friendlier than most developers assume

The Play side deserves more attention than it usually gets, because it hands an embedded agent harness an explicit carve-out.

The policy text permits code that “runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).” That sentence covers the interpretive execution model PhoneBuddy uses, and it does so without requiring the interpreter to be a platform-provided component. The follow-on sentence is the catch: interpreted code loaded at runtime, rather than packaged with the app, “must not allow potential violations of Google Play policies.” In PhoneBuddy’s case the engine and its scripts are packaged with the binary, which keeps the runtime-loading clause off the table — but the compliance burden still lands on the host app, because your tool surface is what a reviewer evaluates.

The practical reading is a two-sided conclusion. Android is the more permissive deployment target for this architecture; iOS is the one that requires a written rationale. That asymmetry should shape an integration plan, not just a review.

The claim nobody can verify: “passes Apple and Google sandbox review”

The README asserts that the SDK “Passes Apple App Store and Google Play app sandbox security reviews with zero permission escalations.” As of 2026-10-01, that assertion could not be substantiated.

• There is no .github directory in the repository tree, so there is no public GitHub Actions workflow and no CI artifact of any kind.
• No review record, correspondence, or third-party attestation is published.
• The only independent technical audit found (covering an August commit) states plainly that no public App Store or Google Play review record was found and that the passed-review claim “remains a project assertion.”

None of that makes the claim false. It makes it unverified, which is a different statement and the one a professional evaluator should carry. If your threat model includes store rejection of a shipping app, “the README says it passed” is not evidence; your own 2.5.2 and DPCLA 3.3.2 analysis is.

What did the independent audit find — and what did it reject?

One third-party technical review exists, published at vibekk.com and covering main at commit c661ba0 (reviewed 2026-08-23). It is worth summarizing honestly, including its limits, because it is the only external verification in the ecosystem.

What it confirmed as static controls:

• No std::process or tokio::process usage
• Path jailing for file access
• Bounded JavaScript execution
• Timeouts and cancellation support
• Repeated-tool detection
• SSRF screening that blocks loopback and private address ranges
• Swift, Kotlin and C integration surfaces

What it rejected or flagged as unsupported:

• The “passes Apple App Store and Google Play” claim, for the absence of any public record
• “Guaranteed FFI panic containment” — a meaningful objection, since the C ABI is precisely where mobile integration happens and where a Rust panic crossing the boundary would be an app crash rather than a caught error

The audit also noted that the repository “defines 174 Rust tests but has no public GitHub Actions workflow or Android instrumentation suite,” and it could not run the tests because the auditing host had no Rust toolchain. One update since then is favourable: the in-tree test count has grown. Counting #[test] and #[tokio::test] attributes in the source on 2026-10-01 yields 381, well above the August figure of 174, and crates/phone-buddy/tests holds four integration test files (e2e_mock.rs, responses_api_tests.rs, task_tests.rs, tool_args_salvage.rs). The caveat is unchanged: with no CI, “tests exist” still does not mean “tests are known to pass on a clean machine.”

Adoption reality check: 36 stars, three releases, one unanswered issue

The project’s public footprint is small, and the right way to read it is “early bet, not infrastructure.”

The temporal pattern is worth noting separately from the totals. Three releases landed in five days in August 2026 (v0.1.1 on the 18th, v0.1.2 on the 19th, v0.2.0 on the 25th). Then main went quiet: HEAD is c2fc7ea, dated 2026-09-13, with no commits in the roughly 2.5 weeks before 2026-10-01. The repository’s updated_at moved on 2026-09-29, but that reflects metadata activity rather than new code.

And the single open issue is the telling one. Issue #1, opened 2026-09-11, asks about a roadmap for Agent Skills and MCP support. It has zero comments and remains open. In a repository with one open issue, leaving it unanswered for three weeks is a signal about maintainer bandwidth — not hostility, just an absence of the throughput you would want before building a product on top of it.

How does the PhoneBuddy agent engine compare to Napaxi, Foundation Models and Gemini Nano?

The competitive frame has two distinct halves, and conflating them is the most common mistake in coverage of this space. One half is other agent harnesses; the other is model runtimes. PhoneBuddy competes in the first and depends on the second.

Napaxi is the closest structural rival: a mobile-native agent SDK with a Rust kernel, an MCP client, a SKILL.md skill registry, 14+ built-in mobile tools, session/workspace/memory handling, background scheduling, cross-app signed actions, device-to-device A2A over LAN with AES-256-GCM, and channel integrations spanning QQ, WeChat, Feishu, Telegram and Bluetooth. On features it is clearly ahead of PhoneBuddy. Its decisive problem for commercial work is the license: GPL-3.0 with no self-serve commercial option is a genuine adoption blocker for a proprietary app. Its live metrics (33 stars, 7 forks, 15 open issues, created 2026-07-01, pushed 2026-09-30) also make it comparably young. On setup it is heavier, requiring Rust plus Git LFS plus NDK/Xcode.

Apple Foundation Models changes the premise. Since iOS 26 the framework exposes the roughly 3-billion-parameter Apple Intelligence model on the Neural Engine, with no download, no API key, and a 32K context. When the phone itself can host the orchestrator, a harness’s value shifts upward to the tool, sandbox and planning layer — which is exactly the layer PhoneBuddy implements and exactly why it is complementary rather than redundant. The trade-off is that the framework’s tool-calling surface is narrower than a full agent harness, and it is Apple-only.

Gemini Nano plays the same role on Android, delivered through ML Kit GenAI and AICore on Pixel and recent Samsung, Xiaomi and Motorola flagships. AICore is sandboxed with no direct internet access, model downloads route through Private Compute Services, and requests are isolated. The familiar caveat applies: device coverage is uneven across OEMs, so a shipping app needs a fallback path.

llama.rn is the counterexample that clarifies the category boundary. At 1,047 stars, MIT-licensed, actively pushed on 2026-10-01, it loads any GGUF model and uses Metal on iOS. It is not a competitor to PhoneBuddy; it is the runtime a PhoneBuddy-based app would call. A useful sanity check on how much of the mobile on-device space is not the agent layer: llama.rn 1,047, LiteRT-LM 6,549, Cactus 6,081, Cactus Needle 12,899, mlc-llm 23,202, MNN 16,159, ncnn 23,905.

The missing model layer: what you still have to supply

PhoneBuddy owns no weights and runs no inference. Its documentation is explicit about the division of labour, and the design has a sharp edge worth knowing before you integrate: the host application supplies the model, and the one-shot generate_text path is deliberately tool-free and returns RouteNotConfigured when no route exists — with no implicit fallback to a bundled model, because there is no bundled model.

A realistic pairing matrix looks like this:

What the engine does contribute on the routing side is a provider layer with health tracking, failover, retry with backoff, and context budget management — the plumbing you would otherwise write yourself. What it does not give you is a local inference path, so “PhoneBuddy runs an LLM on your phone” is a sentence no one should write.

MCP and Agent Skills on mobile: the gap PhoneBuddy has not filled

The mobile MCP problem is real and structural. MCP’s stdio transport assumes a local process on the same machine, which is precisely what a phone app cannot provide. Streamable HTTP made remote MCP viable, and three mobile patterns have emerged: desktop-controls-mobile frameworks (mobile-next/mobile-mcp at roughly 4.1K stars, plus Appium MCP), app-as-MCP-client using Swift or Kotlin SDKs, and device-as-MCP-server.

PhoneBuddy sits on that gap rather than over it. It exposes its own tool set and a host-routing LLM layer, and its only open issue — unanswered since 2026-09-11 — is a request for an Agent Skills and MCP roadmap. For an integrator in 2026, that means the MCP story is yours to build: either bridge the engine’s tools to an MCP client you write, or treat remote MCP over Streamable HTTP as an external dependency the host app manages. Neither is fatal. Both are unbudgeted work the feature list does not mention.

Integration cost and the FFI risk on the C boundary

The integration surface is a C ABI (phone_buddy.h) with Swift and Kotlin wrappers, which is the right choice for reach and the riskiest choice for stability. Two costs deserve explicit budgeting.

First, panic containment. The audit specifically declined to accept “guaranteed FFI panic containment” as proven. That is not pedantry: a Rust panic that unwinds across an FFI boundary is undefined behaviour, and in a mobile app it surfaces as a hard crash of the host process rather than a recoverable error. If you embed this, you should verify containment yourself — wrap calls, exercise error paths, and test on real devices rather than the CLI.

Second, threat surface. An in-process agent that can read and write a jailed directory and execute bounded JavaScript is attack surface inside your app, sharing your process, your memory and your entitlements. The static controls are real — path jailing, SSRF blocking on loopback and private ranges, script loop limits, timeouts, cancellation, repeated-tool detection — but they are controls to verify, not properties to assume. Tool arguments frequently arrive from model output, and model output can be shaped by untrusted content.

Beyond that, budget for the ordinary costs: a Rust toolchain in your build pipeline, cross-compilation for two platforms, an NDK/Xcode setup, and an attribution obligation under the NOTICE that credits grok-build.

The desktop-client impersonation feature, and why it matters commercially

One README feature is distinctly unusual for a mobile SDK: 1:1 network emulation of desktop AI coding clients, including xAI grok-build, OpenAI Codex and Anthropic Claude Code, with User-Agent and wire-schema mimicry.

Read charitably, it is a compatibility convenience — the engine can speak the same protocol as a desktop client, which simplifies testing against existing tooling and lets a mobile app reuse request shapes that are already well-tested against those providers. Read commercially, it is a question mark. Impersonating another vendor’s client identity in outbound traffic raises terms-of-service and provenance questions that a legal review should settle before a commercial launch, not after. This is not a reason to reject the SDK. It is a reason to read the feature with your counsel rather than with a product spec.

Who should embed the PhoneBuddy agent engine today?

The honest split is by risk appetite and by platform.

Reasonable fit today: a team shipping an Android-first app that needs a model-driven tool loop and cannot fork processes; a developer who already uses Apple Foundation Models or Gemini Nano and needs the agent layer above them; a project that values Apache-2.0 permissive licensing over GPL-3.0 alternatives like Napaxi; anyone willing to pin a specific commit and read the source, because the source is small enough (70 .rs files) to actually read.

Better to wait: teams requiring a support contract or vendor SLA; products on a path where an unverified store-review claim is unacceptable; anyone who needs MCP or Agent Skills support now rather than later; and teams without Rust build expertise who would rather pay for maturity than inherit a young codebase.

Decision checklist before you add it to your app

1. Confirm your platform mix — Android is the permissive target; iOS requires a written 2.5.2 / DPCLA 3.3.2 rationale you can defend to a reviewer.
2. Decide your model layer first (Foundation Models, Gemini Nano, llama.rn/LiteRT-LM, or cloud) and confirm the host-routing path works for it, including the no-fallback behaviour of one-shot generation.
3. Verify panic containment across the C ABI on real devices, not in the CLI, before writing product code against it.
4. Pin an exact commit. With 36 stars and no CI, upstream main is not a stable target and version tags lag the code you may be reading.
5. Budget the MCP work explicitly if your roadmap assumes MCP, because it is not shipped.
6. Add a NOTICE attribution step to your release process and run the impersonation feature past legal review.

Verdict

PhoneBuddy agent engine is the most architecturally interesting answer yet to a real and under-discussed constraint: App Review turns “spawn a shell” into an architectural prohibition, and this SDK is built around that prohibition rather than around Linux. The central claim survives independent verification — zero child processes, zero std::process::Command, zero tokio::process across 70 Rust files at main c2fc7ea — and the in-process substitutions (virtual shell, jailed files, bounded boa_engine, in-memory subagents) are coherent designs rather than marketing bullet points. The Apache-2.0 licence is a decisive advantage over Napaxi’s GPL-3.0 for proprietary apps, and the grok-build lineage gives the agent loop real ancestry.

The thinness is equally real. No CI. No published review record behind the store-compliance claim. One open issue asking for MCP support, unanswered. Three releases, then main quiet since 2026-09-13. Adoption in the dozens of stars. And two specific unproven claims — store review passage and FFI panic containment — sit exactly where a commercial embedder takes on risk.

The disposition: a credible early bet with an unusually honest architectural premise, suitable for teams who read source and pin commits, and premature for anyone who needs a vendor’s word to substitute for evidence.

FAQ

Is PhoneBuddy SDK free to use commercially?

Yes. It is Apache-2.0, so it can be embedded in proprietary apps with attribution; the repository ships a NOTICE crediting grok-build. That permissive licence is the decisive advantage over Ant Group’s Napaxi, which is GPL-3.0 and has no self-serve commercial option.

Does PhoneBuddy run an LLM on the phone?

No. PhoneBuddy is the agent harness — planning, tools, sandbox, subagents — and ships no weights. Inference is host-supplied: you pair it with Apple Foundation Models on iOS, Gemini Nano or LiteRT-LM on Android, a GGUF runtime such as llama.rn, or a cloud provider. Its one-shot generate_text path deliberately has no implicit model fallback.

Does it really pass App Store and Google Play review?

Unverified. The README asserts that it passes both sandbox reviews with zero permission escalations, but as of 2026-10-01 no public review record, CI artifact or third-party attestation could be found — and the repository has no .github directory at all. Treat it as a project claim and run your own 2.5.2 and DPCLA 3.3.2 analysis before relying on it.

Does the PhoneBuddy agent engine spawn processes or use fork/exec?

Verified no. A full download of main at commit c2fc7ea contains 70 Rust files with zero std::process::Command, zero tokio::process, no Command::new, and no libc::fork, execv, execl or posix_spawn. File access is jailed, shell commands run as in-memory BusyBox-style applets, and JavaScript runs in a bounded boa_engine interpreter.

Is the embedded JavaScript engine allowed by the app stores?

Platform-dependent. Google Play’s Device and Network Abuse policy explicitly carves out code that “runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser),” which makes an embedded JS engine viable there. Apple is stricter: DPCLA 3.3.2 blesses interpreted code run by the built-in WebKit framework or JavaScriptCore, so a non-WebKit engine such as boa_engine is a position you argue with a reviewer, not a safe harbour.

Sources and verification notes

All figures were refreshed on 2026-10-01 by downloading source and querying primary APIs directly, not inherited from earlier coverage.

• Live repository metrics, releases, commit history and issue state: GitHub REST API for APUS-AI-Lab/PhoneBuddySDK (via authenticated gh CLI; unauthenticated REST search returned 403 rate limits)
• Zero-child-process verification: full tarball of main at c2fc7ea (sha256 prefix d89a0f1899d3fafe, 70 .rs files, 163 tracked paths), grepped for std::process::Command, tokio::process, Command::new, fork, execv, execl, posix_spawn
• Provenance and modifications: NOTICE in the repository; upstream metrics for xai-org/grok-build from the GitHub REST API
• Apple Guideline 2.5.2: https://developer.apple.com/app-store/review/guidelines/ (quoted verbatim)
• Google Play Device and Network Abuse: https://support.google.com/googleplay/android-developer/answer/9888379 (quoted verbatim)
• DPCLA 3.3.2: quoted second-hand from https://appcompliance.io/blog/apple-vibe-coding-crackdown-guideline-2-5-2/ (the direct agreement fetch returned HTML, not the document, on 2026-10-01)
• Independent audit: https://vibekk.com/archives/mobile-ai-agent-in-process-runtime-phonebuddy-audit (main at c661ba0, reviewed 2026-08-23)
• Host LLM routing and one-shot design: https://github.com/APUS-AI-Lab/PhoneBuddySDK/blob/main/docs/llm-routing-and-one-shot-design.md
• Roadmap issue: https://github.com/APUS-AI-Lab/PhoneBuddySDK/issues/1
• Mobile MCP patterns: https://chatforest.com/guides/mcp-mobile-integration
• Napaxi: https://github.com/antgroup/Napaxi
• Apple Foundation Models: https://developer.apple.com/documentation/foundationmodels
• Gemini Nano and AICore: https://developer.android.com/ai/gemini-nano and https://developers.google.com/ml-kit/genai
• llama.rn: https://github.com/mybigday/llama.rn; LiteRT-LM: https://github.com/google-ai-edge/LiteRT-LM; Cactus: https://github.com/cactus-compute/cactus and https://github.com/cactus-compute/needle
• Same-named research project: https://arxiv.org/abs/2606.23049, https://github.com/PhoneBuddyAI/phonebuddy, https://huggingface.co/PhoneBuddyAI/PhoneBuddy-4B

Limitations: the SDK was not compiled or executed for this review; all architecture findings are static source reads plus the independent audit’s static analysis. The 36-star, 3-release, one-open-issue snapshot is a point-in-time measurement dated 2026-10-01 and will drift.