Boosthis

Showing 25 of 29 from the live probe.

• List Rules

  Every Boosthis performance rule available to this runtime, as ids and titles. The index for boosthis_get_rule.

• Get Rule

  Full detail for one rule: title, when_to_apply, evidence, and - for a registered project - the fix_template. fix_available: false means no fix text is served here; fix_note says what would change that. `counterparts` names the same idea's rule in other languages; also_applies_here names the other places in THIS project it applies, with a count, so the work can be finished as a set.

• Get Integration Kit

  A Boosthis kit for THIS project - no upload; the single-use address needs no key, include_files no shell. Withheld reply? Same kit at GET https://www.boosthis.com/api/kit/<runtime> (project key as bearer). runtime picks the kit; see its enum. The reply carries file_list (path + sha256), version and kit_download_once_url (install_command adds typed commands). One kit per runtime, same key. Writing the files is not the install: the kit is wired in, reporting switched on, and the app confirmed chec

• Get Removal Kit

  Removing Boosthis from this project: the ordered sequence, every kit file, the package entries, the config, the calls to strip, and the Boosthis entries in an AI tool's config. Order is load-bearing - forget(), where a kit has one, only reaches the server while the key is set.

• Match Rules For Code

  Ranks Boosthis rules against a code snippet on each rule's id tokens and when_to_apply text, up to 8 candidates. Ranked guesses from a text match, not findings: each rule's when_to_apply settles whether it really applies.

• Check For Update

  Whether a newer Boosthis kit exists for this project, without fetching it: latest_version, update_available, comparison (behind/current/ahead/unknown), the changelog for every release behind, a severity (cosmetic/recommended/important/security) and a recommendation. kit_download_url serves the whole kit. latest_version is authoritative only on the hosted MCP; a local stdio server answers with its own. Withheld reply? Same answer at GET https://www.boosthis.com/api/kit/<runtime>/update (project k

• Session Summary

  Per-screen p50/p75/p95 and worst rating, worst screens first, with p99, spike ratio and stdev spread where the server has them. No read credentials: a dashboard pointer, never empty. Read-only. More projects: `your_projects`.

• Budgets

  The auto-learned baseline (older p95) against the recent p95 for each screen, and which screens regressed. No read credentials: a dashboard pointer, never empty. Read-only. More projects: `your_projects`.

• What Should I Look At Next

  A triage ordering: the worst-rated and slowest screens first, each with a one-line reason. No read credentials: a dashboard pointer, never empty. Read-only. More projects: `your_projects`.

• Snapshot

  The latest upload from one install, whichever sections that runtime records: a phone app has a boot ladder, frame meters and Frustration, a back end none of these. Per-route rows, per-screen diagnosis, summary and budgets where present. No credentials or nothing uploaded yet: a dashboard pointer. Read-only. More projects: `your_projects`.

• Crash Risk

  Crash classes this app recorded - uncaught errors, unhandled rejections and caught render near-misses - newest first, each with an error name, a redacted top frame, an occurrence bucket and relatedRules, joined with the JS-thread (ANR-style) Stability summary and stabilityRules. Signatures are code-derived, never the raw message: no user value is exposed. No credentials, or no crash recorded yet: a note. Read-only.

• Full Stack Trace

  One user action across the stack as a nested waterfall of spans (layer, route label, duration, start offset, rating), each under the call that caused it; criticalHop names the hop responsible for the end-to-end time, not just the longest. Relative timings, code-defined labels only. A read token sees one install, account_token the whole chain. Read-only.

• Connection Status

  What Boosthis knows about this account's installs (same check over plain HTTPS: GET /api/connection-status, project key as bearer): for each, the runtime, its state, when it was last heard from, and what that state means. It answers "is it working?" without guessing - an install that registered but never measured anything reads differently from one that is quiet because the app is. Read-only; returns no credentials.

• Which Kits

  Names which Boosthis kits this project needs, from manifest file names already visible in it - nothing is downloaded or executed. The inventory step before boosthis_get_integration_kit. It names the kit each file implies, the surfaces already registered under this project key, and the files whose contents decide a runtime. With no arguments: the signal table.

• Verify Kit Install

  Check a Boosthis kit's FILES ON DISK are byte-perfect (same check over plain HTTPS: POST https://www.boosthis.com/api/kit/<runtime>/verify) - a pass proves the files, never that anything is measured yet. The verdict names the exact missing, modified and unexpected paths, each with expected sha256. Read-only; returns no credentials.

• Maintenance Mix

  The Maintenance Mix: of the issues a project actually fixed, how many were fixed before users felt them (flagged by a Boosthis rule, app still healthy) versus after a crash or a poor rating. A project with too few fixed issues reports null rather than a made-up ratio. Read-only; returns no credentials.

• Trend

  One project's last 30 days: for each finished day, how many measurements arrived, typical and worst-case screen time, how many were rated poor, new crashes, and alerts opened and closed - plus a plain-English verdict comparing the last 7 days with the 7 before. Days that reported nothing are no_data: unknown, never zero, never healthy. Too few measurements gives not-enough-data, not a guess. Read-only; returns no credentials.

• Vigilance

  One project's standing Vigilance verdict and every watch behind it, worst first: what each watches, what it says now, and the evidence (how many measurements, over which window, on which part, when the app was last heard from). Also what it cannot watch here and why - no history, reporting off, kit too old, part never named - unknowns, never good news. No score. Read-only, returns no credentials, never counted as an AI read.

• Jobs

  Every scheduled job this project reports, each in one state: on time; late; app unheard - reporting stopped before the run was due, so the job is not blamed; never reported a run; or no rhythm declared, so it is remembered, not watched. Each carries its rhythm, how late is too late, when it last finished, whether that run succeeded, and how long runs take. Only names and timings are collected, never arguments or data; Boosthis never runs or schedules a job. Read-only.

• Exposure

  What this app was OBSERVED exposing: leaks, cookie flags, dev settings left on, turned-away traffic, build age, swallowed errors. Each carries its limits; never a safety claim. Read-only.

• Alerts

  This account's Boosthis alerts, in the dashboard's words: Open, Read, Fixed, Returned (marked fixed, then happened again) or Dismissed, each saying whether its screen or check is Muted. The reply states how many matched, so a trimmed list is never mistaken for the whole. Read-only: it cannot mark anything fixed, muted or dismissed, and returns no credentials.

• Promises

  The standing promises this project's developer has recorded - what they want kept as the project changes, surviving earlier sessions and assistants. Each says whether Boosthis can measure it: 'watched' names the exact line it is held to, 'remembered only' is a standing instruction with nothing measuring it. Read-only.

• Remember Promise

  Saves what the developer wants kept true from now on - a screen that must stay fast, a problem that must not come back, a rhythm that must hold - as a promise on the project, in their words, surviving later sessions and other assistants. Restating one replaces it rather than duplicating it. Boosthis says what it reads the sentence to mean; nothing counts as measured until the developer confirms it on their project page. Passwords, keys and personal details are refused, not stored. This one write

• Check Claim

  Holds a sentence an assistant is about to say against what the running app actually did. Exactly one of four answers: supported, not supported by the measurements, cannot tell yet, or outside what Boosthis measures. Boosthis picks the comparison window; one named in the sentence is not used. It catches only a minority of wrong claims - the best measured result in this field is about one in six - and a vague claim is never caught at all. Read-only.

• Release Check

  How the last release held up, from the running app after it shipped. Against the version this project's own measurements reported, six answers: did the problems it was handed fixes for stop, did anything get slower, did new problems appear, did an old one come back, did a recorded promise pass its line, did the changes Boosthis witnessed hold up. Each carries its numbers and window; a part without enough evidence says so, and when it could answer. No combined score. Read-only.