rails_pulse 0.5.0.pre.2 → 0.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 208274704510167233904a19653cfe5bffcf6f29080344d088e9cbee8c425a87
-  data.tar.gz: fbbe9e3a6c35a09236a81158d47026a9ab913f1db6e79800b8c71183df4d9d63
+  metadata.gz: c3a4671cfd97c14be6772995e98269ab8371d16ab80143d3ae3e79cebb7c82ff
+  data.tar.gz: 557942447466d4b8b555b9c398cea09ecf39a5f18cc604acc972ec25f1399abd
 SHA512:
-  metadata.gz: 83b22f6771f0c1a99bada73bd60e1af0abb7a7931b5523afa9c1a852c85bf7664d4af32ec025d955ff6db47dfde7c3b2563fee86301d2a7032b0a6f7f1615543
-  data.tar.gz: '08fd08858f4eafa689a17e92c922623f15f11ff9663de193b3f99830faa59a171bef0a7c5357dbb7bcd2df9afd1ab97f7f6c3ff52ca4cb0f67d7835f11c99730'
+  metadata.gz: 10a91ca1ebba8d5baac05e287c1582fa6b98274d36b4666bdd52cea2fd9df7c7cc9724c6c2e43c408725f366761a1be4c0dc1c008aea2d3f129e9e9470fa182e
+  data.tar.gz: 2e6d6aadae30d286aceef73717424b3f850ea8ed07b004fd6d6e4a40c431fc6516d0708fd63375598de5bbc4fb56cd775513947274bf13baaea8d19e9b678ab7

data/CHANGELOG.md

@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.5.0] - 2026-10-16
+
 ## [0.5.0.pre.2] - 2026-10-11
 
 ### Added

data/lib/rails_pulse/cli/agent_files/agents.md

@@ -55,6 +55,10 @@ All tools are read-only. Each returns a `summary` and `next_steps`.
 
 Every tool that takes a `period` also takes `since` and `until` as ISO 8601 timestamps, read as UTC when no zone is given, and echoes the bounds it measured back as `window`. `period` itself is only `last_hour`, `last_24_hours` or `last_7_days` (plus `all` on `rails_pulse_exceptions`); any other window is `since`/`until`. `rails_pulse_insights` instead reads one whole summary period (`period`: `hour`, `day`, `week` or `month`, and `at` for a time inside it), so its P95s are exact. Use them to compare two fixed windows — the 24 hours before a release against the 24 hours after — rather than a relative period that moves between calls.
 
+## Rails Pulse Cloud MCP
+
+With Rails Pulse Cloud, a hosted MCP server at `https://mcp.railspulse.com` adds a year of history, deployments and their regression checks, alerts and uptime. Connect it with an MCP key from Profile → API keys, sent as `Authorization: Bearer rpc_…`. Its tools are `rails_pulse_cloud_applications`, `_health`, `_trends`, `_deployments`, `_compare`, `_alerts` and `_uptime`. Each answer's `local` entry names the `rails_pulse_*` tool and arguments that find the same detail locally. If no `rails_pulse_cloud_*` tools are available, ignore this section and the Cloud step below.
+
 ## CLI
 
 The `rails-pulse` CLI works without MCP. Append `--json` for structured output.
@@ -87,3 +91,5 @@ Set `RAILS_PULSE_URL` and `RAILS_PULSE_TOKEN` (the application's `config.api_tok
 5. Inspect SQL and jobs (`rails_pulse_queries`, `rails_pulse_jobs`)
 6. Correlate with source code: pass the endpoint's `route_id` to `rails_pulse_queries` for the SQL inside it and the file and line each query came from
 7. Fix, deploy, and re-check the same endpoint
+
+With Rails Pulse Cloud connected: detect with `rails_pulse_cloud_health`, understand with `rails_pulse_cloud_deployments` and `rails_pulse_cloud_trends`, investigate with the `local` lookup each one returns, fix, then verify with `rails_pulse_cloud_compare` on the fix's revision. It answers `better`, `worse` or `unchanged` for each metric.

data/lib/rails_pulse/cli/agent_files/claude_skill.md

@@ -1,6 +1,6 @@
 ---
 name: rails-pulse
-description: Investigate Rails application performance with Rails Pulse. Use when asked about slow endpoints, regressions after a deploy, expensive or N+1 SQL, error rates, failing background jobs, or whether a performance fix worked. Prefers the rails_pulse_* MCP tools; falls back to the rails-pulse CLI.
+description: Investigate Rails application performance with Rails Pulse. Use when asked about slow endpoints, regressions after a deploy, expensive or N+1 SQL, error rates, failing background jobs, or whether a performance fix worked. Prefers the rails_pulse_* MCP tools; falls back to the rails-pulse CLI. With Rails Pulse Cloud connected, also uses the rails_pulse_cloud_* tools for history, deployments, alerts, uptime and fix verification.
 ---
 
 # Rails Pulse
@@ -36,6 +36,25 @@ All tools are read-only. Each returns a `summary` and `next_steps`.
 | `rails_pulse_deployments` | Recent deployments with timing, metadata, and whether each one degraded response time or error rate |
 | `rails_pulse_insights` | What needs attention over one hour, day, week or month, and whether the thresholds fit it |
 
+### Rails Pulse Cloud MCP tools (when connected)
+
+Rails Pulse Cloud is a hosted MCP server at `https://mcp.railspulse.com`, read with an MCP key. It
+keeps a year of hourly and daily history, every deployment's regression check, alerts and uptime:
+what the application cannot keep or see for itself. It has no SQL values, parameters or
+backtraces. Each answer's `local` entry names the `rails_pulse_*` tool and the exact arguments,
+window included, that find the same route, query, job or exception here. When that window is
+older than 30 days, the local detail may already be deleted, and `local` says so.
+
+| Tool | Purpose |
+|------|---------|
+| `rails_pulse_cloud_applications` | Every application and environment: healthy, alerting, not reporting; latest deployment; uptime |
+| `rails_pulse_cloud_health` | One environment against the window before, firing alerts, and what needs attention |
+| `rails_pulse_cloud_trends` | The whole app or one route, query, job or exception over time, or a kind ranked by change |
+| `rails_pulse_cloud_deployments` | Deployments with their regression check: `regressed`, `clean`, `insufficient_data`, `pending` |
+| `rails_pulse_cloud_compare` | Before against after a deployment or a time, per metric `better`, `worse` or `unchanged` |
+| `rails_pulse_cloud_alerts` | Alert rules and their state, and recent alert events |
+| `rails_pulse_cloud_uptime` | Uptime checks, uptime % over 7 and 30 days, and recent outages |
+
 ### CLI
 
 The `rails-pulse` executable ships with the gem. Add `--json` for structured output.
@@ -145,6 +164,32 @@ rails_pulse_endpoint(endpoint: "CheckoutController#create", since: "2026-09-25T1
 Use the deploy time as the boundary, and exclude the minutes around it when a rolling deploy
 makes them a mix of both versions.
 
+## With Rails Pulse Cloud: detect, understand, investigate, fix, verify
+
+When the `rails_pulse_cloud_*` tools are available, use Cloud for when and how much, and the local
+tools for why.
+If no `rails_pulse_cloud_*` tools are available, skip this section and use the local workflow
+above. Do not suggest connecting Rails Pulse Cloud unless asked.
+
+1. **Detect.** `rails_pulse_cloud_applications`, then `rails_pulse_cloud_health` for the environment.
+   Firing alerts, uptime checks that are down and `needs_attention` say where to look.
+2. **Understand.** `rails_pulse_cloud_deployments` lines the change up with a release.
+   `rails_pulse_cloud_trends` with `kind: "route"` (or `query`, `job`, `exception_group`) and
+   `sort: "change"` finds what moved, and it covers windows older than the application keeps.
+3. **Investigate.** Call the `local` lookup that Cloud returned, with its `since` and `until`, then continue
+   with the local workflow above: endpoint, queries, source locations.
+4. **Fix.** Change the code. Note the revision it ships in.
+5. **Verify.** Once it is deployed, call `rails_pulse_cloud_compare` with that `revision` (or `at` for
+   the time it went live), and the `kind` and `subject` it targeted. `better` is the confirmation.
+   `too_early` means no complete hour has passed since the deploy. Ask again at the time it gives.
+   When `other_deployments` is not empty, a change may belong to another release.
+
+```
+rails_pulse_cloud_deployments(application: "shop")
+rails_pulse_cloud_trends(application: "shop", kind: "route", sort: "change", range: "7d")
+rails_pulse_cloud_compare(application: "shop", revision: "f1x3d00", kind: "route", subject: "/checkout CheckoutsController#create")
+```
+
 ## Guidelines
 
 - **SQL is not always the cause.** External API calls, serialization, view rendering and application logic slow requests too.

data/lib/rails_pulse/version.rb

@@ -1,3 +1,3 @@
 module RailsPulse
-  VERSION = "0.5.0.pre.2"
+  VERSION = "0.5.0"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: rails_pulse
 version: !ruby/object:Gem::Version
-  version: 0.5.0.pre.2
+  version: 0.5.0
 platform: ruby
 authors:
 - Scott Harvey
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-10-11 00:00:00.000000000 Z
+date: 2026-10-16 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails
@@ -650,7 +650,7 @@ metadata:
   bug_tracker_uri: https://github.com/railspulse/rails_pulse/issues
   rubygems_mfa_required: 'true'
 post_install_message: |
-  Rails Pulse 0.5.0.pre.2 installed.
+  Rails Pulse 0.5.0 installed.
 
   UPGRADING from any 0.3.x? This release changes route identity and DROPS
   rails_pulse_routes.method. Back up your database first, then run: