Trader observer: jjavi

Read-only observer for reconstructing the public behavior of Polymarket profile jjavi (proxy wallet 0x6ff2cb14da8be7eb57541d250a0196c5f295f140). It is separate from pm-engine and never receives wallet keys, L2 credentials, config.db, or strategy env.

Supported implementation: Rust

The production path is the pm-trader-observer binary in the existing pm-observer crate (переехал из снятого pm-backtest 2026-08-21; имя бинаря не менялось). It reuses pm-sdk Data/Gamma/CLOB clients and types, canonical fixed-point units, and directional project_book. Standalone capture import is not supported: the observer records factual public traffic directly. Only the external-account SQLite schema and statistical report are observer-specific.

Local collection and report:

cargo run -p pm-observer --bin pm-trader-observer -- collect \
  --wallet 0x6ff2cb14da8be7eb57541d250a0196c5f295f140 \
  --data-dir .tmp/jjavi-observer-rust --once \
  --max-activity-offset 0 --max-book-tokens 5 --min-free-gib 1
cargo run -p pm-observer --bin pm-trader-observer -- report \
  --data-dir .tmp/jjavi-observer-rust \
  --out .tmp/jjavi-observer-rust/reports/manual.json

The governed VPS command builds a release binary, verifies SHA-256 before and after installation, installs the hardened user unit, and restarts no trading container:

scripts/deploy-vps.sh trader-observer

The service writes WAL-backed data and hourly reports under instances/harvester-engine/data/trader-observer/jjavi-rust/. It fails loud at the 64 GiB free-space boundary and never deletes source data automatically. Every 15-second cycle persists filesystem total/available/used bytes, used basis points, reserve headroom, and check time in observer_meta; the same snapshot is included as storage in every hourly JSON report and emitted to the systemd journal. This makes the report sequence a durable disk-space trend rather than only discovering exhaustion at the hard boundary. The deployed unit polls books every 15 seconds, retains all tokens already seen in account activity plus the weather universe with ask at or below 1000 pips (10 cents), and refreshes the expensive Gamma universe hourly. Identical raw Data/Gamma bodies occupy one SHA-256-addressed object. The Data API currently refuses historical activity offsets above 5,000. The collector backfills through that inclusive offset, records activity_truncated=1 when the final page remains full, and then short-circuits unchanged later pages without falsely upgrading the dataset to complete.

The collector batches at most 2,000 tokens into 40 POST /books calls per 15-second cycle. pm-sdk::PublicClobClient also enforces the official 500-requests-per-10-seconds sliding budget before every batch call, so a later cadence or universe change cannot silently exceed that endpoint budget. Gamma and Data calls retain their existing per-endpoint budgets. Source: Polymarket rate limits.

Current disk status without stopping the collector:

ssh deploy@poly.grot.app \
  "sqlite3 /home/deploy/pm-backtest/instances/harvester-engine/data/trader-observer/jjavi-rust/observer.db \
  \"SELECT key,value FROM observer_meta WHERE key LIKE 'filesystem_%' ORDER BY key;\""

The JSON report separates BUY and SELL hypotheses and uses exactly one last snapshot received at or before each public fill; both observer receipt time and exchange time must be causal. It compares every matched action with two distinct control cohorts:

• selection_thresholds: synchronized sibling YES buckets from the same Gamma event, answering why this bucket was selected instead of its alternatives;
• timing_thresholds: earlier states of the same token within the configured one-hour lookback, excluding every six-minute window around any public fill, answering why the account acted now rather than earlier.

Both cohorts report point-biserial correlations and one-dimensional <=/>= threshold candidates. Features include fixed price/spread/depth boundaries and relative basis-point measures: spread versus midpoint, signed bid/ask depth imbalance, near-touch concentration, fill versus inventory/average entry, and fill notional versus touch liquidity. Candidate selection uses the first 70% of timestamps; test metrics use the later 30%. Repeated fills can still be correlated, so candidates remain hypotheses until they repeat across longer forward intervals.

lifecycle reports observed entries, adds, partial/full exits, still-open inventory, and empirical hold times. Weather forecasts are intentionally not collected: this observer is scoped to recover boundaries in observable market state at decision time. Raw activity variants remain immutable; analytical TRADE rows are logically deduplicated by transaction hash, timestamp, token, side, price, and size, preferring the most complete metadata variant. Public activity exposes fills, not unfilled/cancelled order intent, and this report does not make a profitability or +EV claim.