/drasi

Currency and AI context bundle

Use this bundle when the task is version-sensitive, asks for the latest Drasi behavior, creates code/docs/examples, changes provider schemas, or updates guidance that may drift.

Purpose

Drasi moves quickly across Drasi Server, Drasi for Kubernetes, drasi-lib, provider plugins, query language support, and reactions. Do not rely on memory for exact schemas, version numbers, CLI arguments, image tags, or API paths.

Authoritative source order

Use this source order for version-sensitive work:

1. Official Drasi AI context: https://drasi.io/reference/context/ and the raw drasi-context.yaml it links to.
2. Current product docs for the target runtime: drasi-lib, Drasi Server, or Drasi for Kubernetes.
3. GitHub releases or tags for the exact component being pinned, plus the official What's New page (https://drasi.io/whats-new/), which tracks feature and documentation deltas that may not surface in individual release notes.
4. crates.io and docs.rs for Rust crates such as drasi-lib.
5. The image registry (GHCR) for the concrete container tag. drasi list reactionprovider / sourceprovider lists provider definitions bundled into the release but does NOT confirm the image is published for that version. A provider can be registered, documented, and still missing its image at a given tag (e.g. reaction-post-dapr-pubsub is registered and documented under 0.10.0 but ghcr.io/drasi-project/reaction-post-dapr-pubsub:0.10.0 returns 404, the tag stops at 0.9.2). Before pinning, verify each component image exists at the target tag with a registry manifest request (use the manifest-list Accept header for multi-arch images).
6. Existing examples only after confirming they match current docs.

Treat copied examples, old blog posts, and previous project scaffolds as helpful but non-authoritative.

Required currency check

Before generating or changing Drasi implementation guidance, record:

Checked date: <YYYY-MM-DD>
Runtime: <drasi-lib | Drasi Server | Drasi for Kubernetes>
Component: <server/platform/source/query/reaction/library>
Version/source checked: <version, release page, docs page, or raw context version>
Schema source: <official docs/API/docs.rs/OpenAPI>
Known drift risk: <summary>

If the current docs and an existing skill example disagree, prefer the current docs and update the example.

Freshness rule

If the recorded checked date is more than 30 days old, treat all versions, schemas, CLI commands, provider lifecycle notes, identity guidance, and examples as stale until re-verified from authoritative sources. For reusable accelerators, set a review trigger on every Drasi release, MCP protocol update, provider lifecycle change, or failed validation run.

Version conflict rule

When official Drasi AI context, product docs, GitHub releases, crates.io, docs.rs, or live OpenAPI disagree:

1. Record each conflicting source and date.
2. Prefer the source that is authoritative for the runtime being implemented.
3. For production, prefer the documented stable baseline unless the user explicitly accepts preview or newer-crate risk.
4. Pin the selected version and include a rollback path.
5. Add a follow-up review item so the conflict is not forgotten.

For drasi-lib, treat this as a concrete three-way pinning decision, not a generic "newer crate is a conflict" hedge:

• 0.8.6 - the version currently called out by the official Drasi AI context's current_stable_version baseline (context 0.7.0, updated 2026-06-16). Choose this for AI-context alignment and portability with context-grounded scaffolds.
• 0.9.0 - latest crates.io release (Aug 20, 2026; minor bump from the 0.8.x line ; core crates moved to ^0.5.8/^0.3.x). Published crates-only: no GitHub release tag or changelog exists for it yet, so diff the trait surface against your current pin before upgrading. Choose this when you need the newest published line and accept unchangelogged drift.
• 0.8.9 - previous crates.io line (Jul 8, 2026). 0.8.7 fixes PostgreSQL datetime preservation, 0.8.8 unifies reactions, 0.8.9 fixes FFI + dashboard.
• Latest crates.io/docs.rs line - may be newer than either named version or the AI-context baseline. Re-check crates.io before pinning; choose a newer line only with explicit rationale and acceptance of potential drift from context-grounded examples.
• Post-Replayable-Sources line (upcoming trait-surface break) - tracked in drasi-core issues #345, #369, #392, #393, #394. See bundles/drasi-lib/guide.md for the trait-surface details (SourceEventWrapper.sequence, Source::supports_replay(), SourceSubscriptionSettings.resume_from, SubscriptionResponse.position_handle). Only reach for this line if you knowingly need replay/recovery and accept break risk.

Pin DELIBERATELY: choose 0.8.6 for AI-context alignment, choose a newer crates.io line only with explicit rationale, or choose the post-Replayable-Sources line only after weighing the upcoming break. Capture the chosen pin in versions.md along with a one-line rationale.

versions.md should also capture the drasi-core commit SHA when pinning unreleased work, since drasi-lib is published from the drasi-project/drasi-core repo and there is no standalone drasi-lib repo to point at.

Upstream organization currency recipe (gh CLI)

Official docs and release pages lag merged code, and significant work ships in org repos outside the flagship ones (design-doc collections, contributor personal repos, new monorepos). Run this sweep when re-verifying currency, then fold findings into the checked-date block above:

# 1. Org inventory: new / archived / renamed repos since the last checked date
gh repo list drasi-project --limit 100 --json name,isFork,pushedAt,isArchived

# 2. Release state per runtime train
gh release list -R drasi-project/drasi-platform --limit 5    # Drasi for Kubernetes
gh release list -R drasi-project/drasi-server --limit 8      # Drasi Server
gh release list -R drasi-project/drasi-core --limit 10       # per-crate releases

# 3. Merged PRs newer than the recorded checked date - breaking changes land here first,
#    often weeks before any release note
gh pr list -R drasi-project/drasi-core     --state merged --limit 30 --json number,title,closedAt
gh pr list -R drasi-project/drasi-platform --state merged --limit 20 --json number,title,closedAt
gh pr list -R drasi-project/drasi-server   --state merged --limit 20 --json number,title,closedAt

# 4. Contributor personal-repo sweep: experimental sources/reactions and draft-spec
#    implementations surface here months before main-repo PRs
gh api 'repos/drasi-project/drasi-core/contributors?per_page=15' --jq '.[].login'   # skip bots
gh api 'users/<login>/repos?sort=pushed&per_page=100' \
  --jq '.[] | select((.name | ascii_downcase) | test("drasi")) | "\(.full_name) :: \(.description // "")"'

Interpretation rules: flag PR titles containing !, BREAKING, feat(, default flips, removals, or security bumps and open those bodies for user-visible impact; treat original (non-fork) repos from core contributors describing integrations or draft extensions as design signals ; record them as emerging-surface notes with [VERIFY], never as shipped guidance.

Anti-drift rules

• Do not invent provider fields. Verify Source, ContinuousQuery, Reaction, Drasi Server, or drasi-lib API shapes against current docs.
• Do not use latest images or unpinned crate versions for production examples.
• Do not assume Drasi Server, Drasi for Kubernetes, and drasi-lib share identical resource formats.
• Do not assume provider lifecycle behavior is uniform. Re-check whether a resource supports re-apply, patch, delete/recreate, or rebuild.
• Do not assume Microsoft Entra Workload ID support unless the provider docs explicitly show it.
• When official context is stale compared with product docs or release artifacts, state the conflict and pin to the product docs/release artifact for implementation.

Prompt hygiene for AI agents

When asking an AI agent to generate Drasi work, include:

• The selected runtime form.
• The official Drasi AI context or a current summary of the checked context.
• The target Drasi versions and whether pre-release components are allowed.
• The exact provider/reaction docs to follow.
• A requirement to include validation commands and expected outputs.
• A requirement to stop rather than guess on missing schemas or unsupported lifecycle operations.

Currency evidence in PRs

For production or reusable scaffolds, require a short evidence block in the PR or release note:

### Drasi currency check

- Checked: <date>
- Runtime: <runtime>
- Versions pinned: <versions/images/crates>
- Docs used: <docs/release pages>
- Known preview/pre-1.0 risks: <risks>
- Follow-up review date: <date or trigger>

Reusable templates for currency evidence

Treat the templates as the source of truth - keep inline snippets above for quick reference, but file the per-PR evidence into these durable artifacts so reviewers and future operators can audit currency posture without rereading the bundle:

• templates/drasi-currency-check.md - the inline currency-evidence snapshot above, lifted into a reusable form for PRs, release notes, and architecture decisions. Use it any time a Drasi project touches a version-sensitive surface.
• templates/drasi-upgrade-evidence.md - the per-upgrade evidence record covering pre-upgrade snapshots, apiVersion diff, lifecycle diff, execution log, post-upgrade validation, and rollback procedure. Use it for every Drasi platform, server, or drasi-lib upgrade that promotes past dev.
• templates/drasi-version-pinning.md - the durable versions.md shape captured by SKILL.md's pinning rule. Currency evidence is incomplete without a matching pinned-versions manifest.

If the inline ### Drasi currency check block disagrees with templates/drasi-currency-check.md, the template wins and the inline block should be updated.