live-drift-resolution

Resolve live service drift issues by regenerating catalog artifacts and classifying upstream changes.

8|6|Updated Jul 31, 2026
One-click install
npx skills add https://github.com/stellar-experimental/stellar-raven --skill live-drift-resolution-stellar-experimental
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: live-drift-resolution
Source: https://github.com/stellar-experimental/stellar-raven/tree/main/.agents/skills/live-drift-resolution
Command: npx skills add https://github.com/stellar-experimental/stellar-raven --skill live-drift-resolution-stellar-experimental

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Daily CI detects when the committed service catalog snapshot no longer matches live upstream surfaces (Lumenloop, Stellar Light/Scout, Stellar Docs) and files a drift issue. This Skill provides the runbook to regenerate the frozen artifacts, classify the drift correctly, and close the loop through commit, deploy, and production verification. ## Core Features & Use Cases - Drift classification: Sorts each upstream change into provenance/data, operation-surface, routing-relevant text, or runner-affecting classes using machine-checkable diffs rather than changelog claims. - Policy and baseline decisions: Guides exposure decisions in scripts/exposure.mjs for newly added operations and routing-gate re-baselining only when text changes genuinely moved routing. - Full close-out pipeline: Covers regeneration, impact audits across evals and improvements, adversarial independent review, secrets scanning, deployment, and live production verification. - Use Case: A daily CI job files a "Live service drift detected" issue after Scout ships a version bump; use this Skill to regenerate inventory and catalog files, prove the bump is routing-neutral, and deploy the updated catalog. ## Quick Start Ask the agent to resolve the latest live service drift issue by regenerating the catalog, classifying the drift from the actual diff, and verifying the routing gate before committing.

Frequently Asked Questions about live-drift-resolution

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I resolve a live service drift detected issue?

Regenerate the pipeline artifacts (refresh-inventory, build-catalog, micro-map, spec, op-classes), then classify the drift from the actual inventory diff as provenance, operation-surface, routing-relevant, or runner-affecting. Commit, deploy with wrangler, verify production, and close the issue with evidence.

How do I tell if an upstream version bump is routing-neutral?

Diff the per-operation operationId, summary, description, and x-routing fields between the old and new inventory JSON. An empty diff means the routing gate must pass against the existing baseline unchanged; never re-baseline to hide a provenance-only bump.

What happens when a drift diff adds a new API operation?

A newly exposed operation is a policy decision under ADR-0003: either expose it or add it to the exclusion data in scripts/exposure.mjs in the same change. The build-catalog guard fails loudly if emitted text references a non-exposed op.

Why does the routing gate fail after a provenance-only drift bump?

If operation descriptions are byte-identical, the gate must pass against the existing baseline. A gate that moves when descriptions did not change indicates a real regression, not a baseline to bump.

Does committing the regenerated catalog update the live service?

No. The catalog and spec are compiled into the Worker bundle and CI does not deploy, so production keeps serving the old version until you run wrangler deploy. Verify the new Version ID and routes after deploying.

When is runner re-verification required during drift resolution?

Whenever the drift touches an operation declared in a runnable skill runner's ops list, machine-checked against RUNNERS in src/skills/runners/index.ts. Re-run the live smoke and re-verify projections against observed live payload shapes before closing.