mirror of
https://github.com/software-mansion/argent.git
synced 2026-09-14 19:27:14 +08:00
filip131311
4975ff490c
## Why
PostHog (30d) shows the debugger tool family is argent's least reliable
surface:
| tool | fail rate | dominant causes |
|---|---|---|
| `debugger-status` | **37%** | METRO_NO_TARGETS /
SERVICE_INITIALIZATION_FAILED / zod |
| `debugger-connect` | **24%** | SERVICE_INITIALIZATION_FAILED (~7k, >1k
users), METRO_NO_TARGETS |
| `debugger-log-registry` | 41.7% raw / 4.2% excl. storms | one user
retry-looped it **12,742×** on NO_TARGETS |
Three design issues drive this: (1) "app/Metro not ready yet" — an
expected precondition — is reported as a tool *error*, which both
inflates fail rates and invites agent retry storms; (2) every CDP
init/lifecycle fault lands in telemetry as the catch-all
`REGISTRY_SERVICE_INITIALIZATION_FAILED` with `error_kind=unknown`; (3)
~600 users/30d hit zod validation failures with zero visibility into
which parameter was wrong.
## What
**1. Classified failures** (`d71efa43`) — six former plain-`Error` sites
in `cdp-client.ts` / `target-selection.ts` now carry dedicated
`DEBUGGER_CDP_*` / `DEBUGGER_TARGET_DEVICE_MISMATCH` signals (messages
byte-identical). The registry's two causeless "terminating window"
`ServiceInitializationError`s get their own
`REGISTRY_SERVICE_TERMINATING` code.
**2. Narrow recovery** (`ff9c1955`) — `recoverable()` on both debugger
blueprints, scoped to windows where retry is provably safe: Metro
recovers only `DEBUGGER_CDP_NOT_CONNECTED` (request never left the host;
a detected socket death already self-heals for the *next* call via the
terminated cascade — recovering `CONNECTION_CLOSED` there would be dead
code, see the blueprint comment). Chromium also recovers
`CONNECTION_CLOSED` for the tab-switch reconnect window.
`REQUEST_TIMEOUT` stays unrecoverable (double-execution risk). A
reachability test proves the retry actually fires for a RUNNING node.
**3. Structured not-connected results** (`48b91ffd`) — `debugger-status`
and `debugger-log-registry` become factories that return `{ status:
"not_connected", reason, detail, guidance }` for classified
preconditions (`metro_not_running | no_app_connected | device_mismatch |
cdp_unreachable | stale_connection | reconnecting`) and still throw on
unexpected faults. `detail` preserves the original error text for
string-matching agents. `debugger-status` gains a socket-state gate
(Metro: dispose stale node; Chromium: report transient reconnect, no
dispose — the client belongs to the ChromiumCdp dependency).
log-registry keeps **no** gate on purpose: captured logs are readable
over a dead socket, and disposal would destroy the post-crash log file.
Flows/run-sequence map a not_connected result to a **failed step**
(mirrors `isUnmetUiWaitResult`) so recorded connectivity gates don't
silently pass. `debugger-evaluate` re-codes agent-expression throws as
`DEBUGGER_EVALUATE_EXPRESSION_THREW`.
**4. Telemetry + guidance + docs** (`7602a70d`) —
`tool:fail.invalid_params` (schema-declared names only; unknown keys →
literal `"unrecognized_keys"`; capped emit-side at 16), new
`debugger:tool_outcome` event (coded enum; joins
`tool:invoke`/`complete` via `tool_invocation_id` —
`ai_client`/`duration` live on the joined row), anti-retry-loop guidance
appended to the Metro discovery errors (first sentences verbatim —
skills match on them), six skills updated, Telemetry.md bumped to v1.03
with the new coded diagnostics disclosed.
## Dashboard migration note
`debugger-status` / `debugger-log-registry` precondition failures stop
emitting `tool:fail` — track them via `debugger:tool_outcome` (`outcome
!= 'connected'`). Per-AI-client breakdowns of those outcomes need a join
on `tool_invocation_id` against `tool:complete`.
## Testing
- Full suites green: tool-server 3,142, telemetry 290, registry 87. New
coverage: recoverable truth tables (incl. non-Error inputs), status
not-connected matrix
(Metro/Chromium/terminating-window/stale/dispose-side-effect/fall-through-rethrow),
log-registry rows, zod `invalid_params` derivation + emission-level
guard, flow gate, evaluate rewrap, sanitize-level enum checks.
- Live-tested against a booted iOS simulator + RN app and an Electron
target (details in PR comments).
Plan hardened through 3 adversarial review rounds (46 confirmed findings
addressed) before implementation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
125 lines
8.7 KiB
Markdown
125 lines
8.7 KiB
Markdown
# Argent Privacy Notice (Telemetry)
|
|
|
|
Effective date: 31 July 2026 · Version: 1.03
|
|
|
|
This notice is a product-specific supplement to the [Software Mansion Privacy Policy](https://swmansion.com/) (the "Policy") and applies to telemetry collected by Argent, a Software Mansion Software Product. Capitalised terms used but not defined here (including Personal Data, Usage Data, Legitimate Interest, EEA and Software Mansion Software Product) have the meaning given to them in the Policy. Where this notice and the Policy differ in respect of Argent telemetry, this notice prevails.
|
|
|
|
Argent collects a small amount of usage and diagnostic data ("telemetry") to help us understand how the tool is used and to make it more reliable. We have designed it to be minimal by default: we do not collect the content of your work - no source code, no file paths, no tool inputs, no application data, no error messages, and no device identifiers.
|
|
|
|
## How to opt out
|
|
|
|
Telemetry is enabled by default. You can disable it at any time, and the change takes effect immediately and permanently for that installation. This is also how you exercise your right to object (see Your rights below).
|
|
|
|
```bash
|
|
argent telemetry disable
|
|
```
|
|
|
|
To check the current status:
|
|
|
|
```bash
|
|
argent telemetry status
|
|
```
|
|
|
|
Disabling telemetry does not affect any functionality of Argent.
|
|
|
|
## Why we collect telemetry
|
|
|
|
We use telemetry, in our Legitimate Interest, only to:
|
|
|
|
- understand which features are used, so we can prioritise development;
|
|
- detect where installation, updates, or tools fail, so we can fix them;
|
|
- measure reliability and performance (e.g. how long operations run, error rates);
|
|
- understand the environments Argent runs in (operating system, runtime versions, terminal vs CI);
|
|
- measure how many distinct devices use Argent, without over-counting reinstallations.
|
|
|
|
We do not use telemetry for advertising, marketing, profiling, automated decision-making, or sale of data, and we never combine it with any account or with Personal Data collected through other Services.
|
|
|
|
## What we collect
|
|
|
|
### Installation, update and uninstallation
|
|
|
|
- the progress of an installation: which options were selected; whether it started, completed, failed, or was cancelled; and at which step it was cancelled;
|
|
- the progress of an update to a newer version;
|
|
- the progress of an uninstallation of Argent.
|
|
|
|
### Tool and process usage
|
|
|
|
- which Argent tools are invoked, and whether they succeeded or returned an error;
|
|
- which AI coding tool is driving Argent;
|
|
- how long a process ran in the terminal or in CI, and which Argent component emitted the event;
|
|
- start and stop of the Argent tool-server, its uptime, the number of tools used, and the reason it stopped.
|
|
|
|
### Design review (Argent Lens)
|
|
|
|
When you use the Argent Lens design-review flow (previewing and choosing between proposed UI variants), we collect aggregate, non-content signals about the review interaction:
|
|
|
|
- that a human opened the review preview for a round, and whether the review was completed or abandoned;
|
|
- per-round aggregate counts only: how many elements and variants were proposed, and how many per-element comments, skipped-element comments, and free-form annotations were left — never the comment text, element names, variant code, or file paths;
|
|
- whether a round carried a round-wide comment, and whether the optional comment inspector or "reveal off-screen choices" affordances were used;
|
|
- how long a review round took, from the first proposal to submission;
|
|
- how many times the `argent lens` command was run, and how many coding-agent choices its picker offered (a count only, never the agent names).
|
|
|
|
### Environment
|
|
|
|
- Argent version, Node.js version, operating system, processor architecture;
|
|
- whether the process runs in an interactive terminal and whether it runs in a CI environment;
|
|
- whether Argent is used in connection with Android, iOS, tvOS (Apple TV), Android TV, VegaOS, or a Chromium-based target.
|
|
|
|
### Diagnostics
|
|
|
|
- the fact that an error occurred (event type and code only — never the error content or message);
|
|
- when a tool call is rejected because its parameters fail validation: which parameter names failed. These names come exclusively from Argent's own published tool schemas — never the values you supplied, and never key names you typed that are not part of the schema (an unrecognised key is recorded only as the fixed marker "unrecognized_keys", not the key itself);
|
|
- the outcome of a debugger connectivity check, recorded as one of a fixed set of coded reasons (for example: connected, Metro not running, no app attached) — never the underlying error text.
|
|
|
|
### Identifiers
|
|
|
|
- an installation identifier used to distinguish devices and to de-duplicate events. It is a **one-way HMAC-SHA256 hash derived from a device identifier: the raw device identifier** is never transmitted or stored and cannot be recovered from the hash. The identifier is stable across installations and reinstallations of Argent on the same device, so that reinstalling Argent does not create a new counted user. It is not linked to your name, username, or any account;
|
|
- a random session identifier generated for each usage session.
|
|
|
|
## What we never collect
|
|
|
|
To be explicit, Argent telemetry never includes:
|
|
|
|
- tool input or argument values (for a rejected call we record only which schema-declared parameter names failed validation, as described under Diagnostics — never their values, and never key names that are not part of Argent's own schemas);
|
|
- file paths or file names;
|
|
- source code or its contents;
|
|
- application data;
|
|
- device identifiers (e.g. hardware IDs, MAC addresses, serial numbers);
|
|
- the content or text of error messages.
|
|
|
|
## Who we disclose the data to
|
|
|
|
We use PostHog (provided by PostHog, Inc., San Francisco, USA) as our product analytics provider, acting as our processor under a Data Processing Agreement.
|
|
|
|
Telemetry data is hosted in the European Union (Frankfurt, Germany) on PostHog's EU Cloud. PostHog engages its own sub-processors (cloud hosting and operational monitoring) located in the EU for the EU Cloud and keeps this list to a strict minimum. You can find the current list of PostHog sub-processors on PostHog's website, and a set of useful links is available from us on request.
|
|
|
|
## Legal basis for processing
|
|
|
|
The controller is Software Mansion S.A. (details below). To the extent that the telemetry described here constitutes Personal Data, we process it on the basis of our Legitimate Interest (Article 6(1)(f) GDPR) in maintaining, securing, and improving Argent, consistent with the legitimate-interest grounds set out in the Policy. We have carried out a balancing assessment, taking into account the minimal and non-content nature of the data and the simple opt-out above, and concluded that this interest is not overridden by your interests or fundamental rights and freedoms. You may object to this processing at any time by opting out.
|
|
|
|
## How long we keep the data
|
|
|
|
Telemetry events are retained for up to 72 months, after which they are deleted or aggregated into non-identifiable statistics.
|
|
|
|
## International data transfers
|
|
|
|
Telemetry data is stored within the EEA (Germany). As PostHog, Inc. is established in the United States, access from outside the EEA (e.g. for support) may occur and is governed by the European Commission's Standard Contractual Clauses.
|
|
|
|
## Your rights
|
|
|
|
Subject to the conditions in the GDPR, you have the right of access, rectification, erasure, restriction of processing, data portability, and the right to object, as described in the Data Subject Rights section of the Policy. Because the data is not linked to a named individual or account, we may be unable to identify your specific records without additional information from you (Article 11 GDPR); the most effective way to stop processing is to opt out as described above.
|
|
|
|
To exercise these rights, contact us at legal@swmansion.com.
|
|
|
|
You also have the right to lodge a complaint with a competent supervisory authority. In Poland this is the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa.
|
|
|
|
## Controller and contact
|
|
|
|
The controller of your Personal Data is Software Mansion S.A., a joint stock company with its principal place of business at ul. Zabłocie 43b, 30-701 Kraków, Poland, entered in the register of businesses conducted by the District Court in Kraków for Kraków-Śródmieście, XI Commercial Division of the National Court Register with KRS number 0000961952, NIP 6793131302, REGON 364909814.
|
|
|
|
For any questions or requests regarding this notice, contact us at legal@swmansion.com.
|
|
|
|
## Changes to this notice
|
|
|
|
We may update this notice as Argent evolves. The most current version will be available with the effective date and version shown at the top, and material changes will be announced through the usual Argent release channels.
|