diff --git a/.claude/plugin/plugin.json b/.claude/plugin/plugin.json new file mode 100644 index 00000000..906d0d24 --- /dev/null +++ b/.claude/plugin/plugin.json @@ -0,0 +1,49 @@ +{ + "name": "opentdf-test-harness", + "version": "0.1.0", + "description": "Jira-ticket-driven scenarios for the OpenTDF test harness. Pulls ticket context from Jira (acli) — any ticket type, including bugs, feature stories, and PR-driven work — provisions pinned platform/KAS/SDK versions or refs (released versions, main, feature branches, PR SHAs), runs the xtest pytest suite, and tears down. Useful for QA, platform/SDK developers writing tests for new features first, and downstream first/third-party integrators.", + "skills_dir": "../skills", + "skills": [ + "feature-design", + "scenario-from-ticket", + "scenario-matrix", + "scenario-up", + "scenario-run", + "scenario-tear-down", + "instance-status" + ], + "requirements": [ + "uv (python package manager) on PATH", + "go toolchain (platform binaries are built from source)", + "git (for worktrees of opentdf/platform)", + "docker (for keycloak/postgres dependencies)", + "acli (Atlassian CLI; needed for the scenario-from-ticket skill)", + "gh (GitHub CLI; needed for scenario-matrix to resolve PR refs)" + ], + "permissions": { + "allow": [ + "Bash(uv run otdf-local *)", + "Bash(uv run otdf-sdk-mgr *)", + "Bash(uv run pytest *)", + "Bash(acli jira workitem view *)", + "Bash(acli jira workitem search *)", + "Bash(acli jira workitem comment list *)", + "Bash(acli jira workitem comment create *)", + "Bash(acli jira workitem attachment list *)", + "Bash(acli jira workitem link list *)", + "Bash(acli jira project view *)", + "Skill(feature-design)", + "Skill(scenario-from-ticket)", + "Skill(scenario-matrix)", + "Skill(scenario-up)", + "Skill(scenario-run)", + "Skill(scenario-tear-down)", + "Skill(instance-status)", + "Write(xtest/scenarios/**)", + "Write(xtest/features/**)", + "Write(xtest/bugs/*_test.py)", + "Write(tests/instances/**)" + ] + }, + "permission_notes": "acli jira write-paths intentionally excluded: edit/delete/transition/assign/archive/clone/create/create-bulk/link create/watcher add/comment update/comment delete. Add them explicitly via .claude/settings.local.json if your team needs them; the default plugin is read+comment only." +} diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 00000000..a14484c3 --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,34 @@ +{ + "permissions": { + "allow": [ + "Bash(uv run otdf-local *)", + "Bash(uv run otdf-sdk-mgr *)", + "Bash(uv run pytest *)", + "Bash(uv sync *)", + "Bash(git status *)", + "Bash(git diff *)", + "Bash(git log *)", + "Bash(git show *)", + "Bash(gh api *)", + "Bash(gh issue view *)", + "Bash(gh pr view *)", + "Bash(gh run *)", + "Bash(acli jira workitem view *)", + "Bash(acli jira workitem search *)", + "Bash(acli jira workitem comment list *)", + "Bash(acli jira workitem comment create *)", + "Bash(acli jira workitem attachment list *)", + "Bash(acli jira workitem link list *)", + "Bash(acli jira workitem watcher list *)", + "Bash(acli jira project view *)", + "Bash(acli jira board view *)", + "Bash(acli jira sprint view *)", + "Skill(*)", + "Write(xtest/scenarios/**)", + "Write(xtest/features/**)", + "Write(xtest/bugs/*_test.py)", + "Write(tests/instances/**)", + "Write(.claude/tmp/**)" + ] + } +} diff --git a/.claude/skills/feature-design/SKILL.md b/.claude/skills/feature-design/SKILL.md new file mode 100644 index 00000000..4e1482e1 --- /dev/null +++ b/.claude/skills/feature-design/SKILL.md @@ -0,0 +1,118 @@ +--- +name: feature-design +description: This skill should be used when the user asks to "design a cross-repo feature", "set up a feature spec", "draft a feature across platform and SDKs", "design a fix that spans repos", or wants the tests-side artifacts + per-repo todo lists set up in one pass for work that crosses platform + Go/Java/JS SDKs. Hands off to `feature-orchestrate` for the per-repo PR work. +allowed-tools: Bash, Read, Write, Edit, Grep, Glob, Skill +--- + +# feature-design + +Turn a fuzzy "let's build X across the OpenTDF repos" into a concrete bundle of artifacts that pin down the tests-side work first and stage the cross-repo work for handoff to `feature-orchestrate`. + +Two ideas to internalize before reading the steps: + +1. **Tests-side artifacts land first, dormant.** The scenario + draft test + `feature_type` entry merge to `tests/main` as a regular PR. They stay "all skipped" until each SDK opens its own PR adding a `supports ` case to its `cli.sh` source — that PR's CI activates the test for that SDK. No cross-PR lockstep coordination; per-repo PRs land async, in any order. +2. **Propose, don't ask.** Draft a complete spec from the Jira ticket on the first pass and let the user redirect what's wrong in a single revision. Only ask one composite question. If information is missing that can't be filled in (no Jira ticket, ambiguous scope, unclear feature name), bail — don't fabricate. + +## Inputs + +- Jira key (Story/Task usually; Bug works the same way), OR a free-text description of the feature. +- (Optional) explicit list of repos to scope to, if the user wants something tighter than the default. + +## Steps + +### Step 1 — Pull the Jira context + +If a Jira key was given, run both — `view` takes the key positionally, `comment list` requires `--key`; comments often carry scope refinements: + +```bash +acli jira workitem view --fields '*all' --json +acli jira workitem comment list --key +``` + +Extract Issue Type, summary, description, status, and any comments about scope or implementation notes. If no Jira key, the user's description IS the spec input. + +### Step 2 — Propose a complete draft + +Draft the full spec body and the per-repo todo lists inline in the reply. Don't ask the user one field at a time — produce a complete first draft they can react to: + +- **Feature flag name** — snake_case identifier derived from the Jira summary. Becomes the `supports("")` gate string AND the `feature_type` entry in `xtest/tdfs.py`. Validate it's a valid Python identifier and doesn't collide with an existing `feature_type` member. +- **Touched repos** — default set is `tests, platform, sdk-go, sdk-java, sdk-web`. Trim or expand based on what the ticket says. Pure platform features skip the SDK repos; pure SDK-only features skip platform; `tests` is always present (the dormant scenario + tdfs.py entry has to live there). +- **Per-repo todo lists** — 2–4 bullets per repo: + - `tests` — register the feature in `feature_type`, author the scenario, draft the test gated on `supports("")`. + - `platform` — service-side implementation (KAS path, policy plumbing, etc.) and any env-var handling in the dev harness (e.g. honoring `XT_WITH_`). + - `sdk-go` / `sdk-java` / `sdk-web` — encrypt/decrypt path implementation, plus a `supports ` case in that SDK's `cli.sh` source. **Don't pin the version bound in the spec** — the implementing engineer sets the `awk` predicate at PR time, since the bound depends on which release will ship the impl. +- **Branch name** — `-`, the same string across every touched repo so `feature-orchestrate` (and the user) can find each repo's PR by branch alone. + +Present the draft, then ask exactly one composite question: "Anything to redirect — feature name, touched repos, todo items, branch?" Apply edits in a single revision rather than turn-by-turn. The user can always drop into plain chat if they want to think out loud — answer normally and re-invoke this skill once the design firms up. + +If no Jira key was given AND the user's description doesn't pin down a clear scope (feature flag name, touched repos, intended behavior), bail rather than fabricate: + +``` +I need either (a) a Jira Story/Task/Bug key, or (b) a description that names +the feature flag, the repos it touches, and the intended behavior. Add either +and re-invoke this skill. +``` + +### Step 3 — Write the spec + +Write `xtest/features/.yaml`. Shape (still informal — no Pydantic model yet): + +```yaml +apiVersion: opentdf.io/v1alpha1 +kind: Feature +metadata: + name: # supports() string + feature_type entry, snake_case + jira: # omit if no ticket + title: "" + created: +repos: + tests: + branch: - + todo: + - Register "" in xtest/tdfs.py feature_type + - Author scenario + draft test (via scenario-from-ticket) + platform: + branch: - + todo: [ ... ] + sdk-go: + branch: - + todo: + - Implement in the encrypt/decrypt path + - Add `supports ` case to cli.sh with version-bound awk predicate + sdk-java: { branch: ..., todo: [ ... ] } + sdk-web: { branch: ..., todo: [ ... ] } +scenarios: + - xtest/scenarios/.yaml +``` + +PR status (open/merged/CI passing) deliberately is NOT in the spec — it's auto-discovered from `gh pr list --search "head:"` per repo whenever something asks "where are we?" The spec is a declaration of intent. + +### Step 4 — Drive the tests-side artifacts + +In this order, so each step's output feeds the next: + +1. **Add the feature flag to `xtest/tdfs.py`**. Find the `feature_type` Literal alias near the top of the file. Insert the new entry alphabetically. Don't touch any `cli.sh` files — `supports ` cases land per-SDK in their own PRs. + +2. **Invoke `scenario-from-ticket`** via the Skill tool (`skill: scenario-from-ticket`, `args: `). It runs its Story/Task branch and produces the scenario + draft test gated on `supports("")`. If no Jira key was given, draft the scenario directly using the same shape (`xtest/scenarios/.yaml`). + +3. **Validate the scenario**: + + ```bash + uv run python -m otdf_sdk_mgr.schema validate xtest/scenarios/.yaml + ``` + +### Step 5 — Report + +One block summarizing: + +- The spec path (`xtest/features/.yaml`). +- The scenario + draft test paths. +- The line(s) added to `xtest/tdfs.py`. +- A one-liner suggesting next steps: `feature-orchestrate xtest/features/.yaml` (for per-repo PR work), or `scenario-up xtest/scenarios/.yaml` + `scenario-doctor ` (to bring the dormant scenario up against `main` and confirm "all skipped" baseline before SDK work starts). + +## Notes + +- This skill produces **tests-side artifacts only**. It does NOT create branches in other repos, does NOT open PRs, does NOT install platform/SDK builds. That's `feature-orchestrate`'s job. +- Bugs that span repos use the same shape — pass the Bug ticket key and `scenario-from-ticket`'s Bug branch fills `expected:` / `actual:` from the reproduction prose. The cross-repo gating still works: tests land dormant, each per-repo PR activates them by adding the supports case as part of the fix. +- For an existing spec being revised, read it first and propose a diff rather than a full rewrite. The tests-side artifacts (scenario, tdfs.py entry) usually shouldn't be regenerated — edit them surgically. +- If the user starts the conversation by describing the feature in plain chat rather than invoking this skill, answer normally — re-invoke the skill once the scope firms up. Don't gatekeep. diff --git a/.claude/skills/instance-status/SKILL.md b/.claude/skills/instance-status/SKILL.md new file mode 100644 index 00000000..9467c2b4 --- /dev/null +++ b/.claude/skills/instance-status/SKILL.md @@ -0,0 +1,80 @@ +--- +name: instance-status +description: This skill should be used when the user asks "what's running", "check ports", "show instance status", "list test instances", "are any services up", or before invoking `scenario-up` to detect port collisions (including from sibling git worktrees). For deeper "does the running env match what the scenario yaml says" verification, defer to `scenario-doctor` instead. +allowed-tools: Bash, Read +--- + +# instance-status + +Report a snapshot of test environment state: which instances are defined in this worktree, what is actually listening on the conventional ports (regardless of which worktree owns it), and whether each service is healthy. Surface port collisions before they bite `scenario-up`. + +## Process + +### Step 0 — Cross-worktree probe (always first) + +`otdf-local instance ls` is scoped to the current worktree's `tests/instances/`. Sibling worktrees' running services are invisible to that listing but very much listening on the host's ports. Probe the host directly: + +```bash +bash ${CLAUDE_PLUGIN_ROOT:-.}/skills/instance-status/scripts/cross-worktree-probe.sh +``` + +Output is tab-separated, one row per listener: + +``` +port proto pid cwd kind +8080 tcp 28656 /Users/.../reproducing-things/... platform +8585 tcp 28684 /Users/.../reproducing-things/... kas +compose docker - main compose-project +``` + +Carry forward two facts into the rest of the report: +1. Which of the conventional ports (`8080`, `8181..8686`, `5432`, `8888`) are occupied. +2. The owning `cwd` for each — when it differs from the current worktree, label the line as **foreign** in the final summary so the user knows to tear that down before re-using the port. + +### Step 1 — List instances on disk + +```bash +uv run otdf-local instance ls --json +``` + +Each entry includes `name`, `platform` version, `ports_base`, and the `kas:` keys. Two checks: +- Flag any two local instances that share a `ports_base` — they cannot run concurrently. +- Note: this listing is **worktree-scoped**. The cross-worktree probe from Step 0 is the source of truth for "what's actually using port X." + +### Step 2 — Per-instance status + +For each local instance from Step 1: + +```bash +uv run otdf-local --instance status --json +``` + +Each service reports `running`, `healthy`, and the bound port. Run sequentially (a status query is cheap; parallel adds nothing). Cross-reference each "running" entry with Step 0's table — if the port shows `kind=platform` but the owning `cwd` is a sibling worktree, the local instance's status reading is misleading (it's reporting on someone else's binary). + +### Step 3 — Summarize + +Compose the reply in this order: +1. **Cross-worktree listeners** — the Step 0 table, with each foreign row labeled. Skip if no ports are occupied. +2. **Local instances** — one short block per instance: service → port → state (running/healthy). Mark each row's port as `local` or `foreign` based on Step 0's owner. +3. **Port-base collisions** — any pair of local instances with the same `ports_base`, recommending a re-init: `uv run otdf-local instance init --from-scenario --ports-base `. +4. **Unhealthy rows** — each with the path to its log (e.g. `tests/instances//logs/kas-alpha.log`). + +Skip empty sections rather than print "(none)". + +## When ports collide + +If Step 0 shows a foreign listener on a port the user is about to use, two paths: +- Tear down the foreign instance first. Find the owning worktree from the `cwd` column; cd there and run `OTDF_LOCAL_INSTANCE_NAME= uv run otdf-local down`. +- Or pick a different ports base for the new instance: `uv run otdf-local instance init --from-scenario --ports-base 9080` (or any free base). + +If `otdf-local instance init` warns about a local collision at creation time, it doesn't enforce it; re-running with `--ports-base ` is the fix. + +## What this skill does NOT do + +For the deeper question "is the binary serving port X actually the one my scenario YAML pinned?", use `scenario-doctor` — that skill diffs the running service's `.version` sidecar against the instance's expected pin. `instance-status` reports *what's listening*, not *whether it's the right thing*. + +## Additional Resources + +### Script + +- **`scripts/cross-worktree-probe.sh`** — surveys conventional ports + docker compose projects across all worktrees on this host. Always run first in Step 0. Tab-separated stdout (header on line 1). diff --git a/.claude/skills/instance-status/scripts/cross-worktree-probe.sh b/.claude/skills/instance-status/scripts/cross-worktree-probe.sh new file mode 100755 index 00000000..baed227f --- /dev/null +++ b/.claude/skills/instance-status/scripts/cross-worktree-probe.sh @@ -0,0 +1,57 @@ +#!/usr/bin/env bash +# cross-worktree-probe.sh — surface listeners on opentdf test ports across ALL worktrees. +# +# `otdf-local instance ls` is scoped to one worktree's tests/instances/; sibling +# worktrees' running services are invisible to it. This script probes the host +# directly so the agent can detect cross-worktree port collisions before +# `scenario-up` (or explain why a port appears "free" from one CLI but isn't). +# +# Output: tab-separated, one record per line, header on first line. +# Columns: port proto pid cwd kind +# kind ∈ { platform | kas | docker-keycloak | docker-postgres | unknown } + +set -u + +PORTS=(8080 8181 8282 8383 8484 8585 8686 5432 8888) + +printf 'port\tproto\tpid\tcwd\tkind\n' + +for port in "${PORTS[@]}"; do + # -F to use parseable format; -n -P to skip name resolution (faster) + while IFS= read -r line; do + [[ -z "$line" ]] && continue + pid="$(awk '{print $2}' <<<"$line")" + [[ -z "$pid" || "$pid" == "PID" ]] && continue + + cwd="$(lsof -p "$pid" -d cwd -Fn 2>/dev/null | awk '/^n/ { sub(/^n/,""); print; exit }')" + cwd="${cwd:-?}" + + cmd="$(ps -o command= -p "$pid" 2>/dev/null | head -c 200)" + case "$port" in + 8080) kind=platform ;; + 8181|8282|8383|8484|8585|8686) kind=kas ;; + 8888) kind=docker-keycloak ;; + 5432) kind=docker-postgres ;; + *) kind=unknown ;; + esac + # Refine kind if process command says otherwise (e.g. a misbound port). + case "$cmd" in + *"/service "*|*"/service start"*) kind=platform ;; + *opentdf-kas*|*"kas start"*) kind=kas ;; + esac + + printf '%s\ttcp\t%s\t%s\t%s\n' "$port" "$pid" "$cwd" "$kind" + done < <(lsof -nP -iTCP:"$port" -sTCP:LISTEN 2>/dev/null | tail -n +2) +done + +# Docker compose projects sharing the host docker daemon — names like +# `-keycloak-1`, `-opentdfdb-1`. The project is whatever +# directory `docker compose` was invoked from (typically a worktree's +# xtest/platform/src// directory). +docker ps --format '{{.Names}}' 2>/dev/null | while IFS= read -r name; do + [[ -z "$name" ]] && continue + case "$name" in + *-keycloak-*) printf 'compose\tdocker\t-\t%s\tcompose-project\n' "${name%-keycloak-*}" ;; + *-opentdfdb-*) printf 'compose\tdocker\t-\t%s\tcompose-project\n' "${name%-opentdfdb-*}" ;; + esac +done | sort -u diff --git a/.claude/skills/scenario-doctor/SKILL.md b/.claude/skills/scenario-doctor/SKILL.md new file mode 100644 index 00000000..fb918c68 --- /dev/null +++ b/.claude/skills/scenario-doctor/SKILL.md @@ -0,0 +1,96 @@ +--- +name: scenario-doctor +description: This skill should be used when the user asks to "verify my instance", "doctor my scenario", "is my environment healthy", "does the running platform match the scenario", or to diagnose a flaky test run by confirming the expected binaries / keys / health are actually live. Cross-checks running state against `tests/instances//instance.yaml`. +allowed-tools: Bash, Read +--- + +# scenario-doctor + +Cross-check what an instance's `instance.yaml` *intends* against what is *actually* running, and produce a verdict the user can act on. Most "the test failed for a weird reason" sessions trace back to a drift here — the wrong binary serving the port, stale keys in the worktree, an extra service from a sibling worktree squatting on a port, or a process owned by a different worktree's `otdf-local`. + +## Inputs + +- Instance name (typically the lowercased Jira key, e.g. `dspx-3302`). If a scenario YAML path is provided instead, read its `instance.metadata.name` and proceed. + +## Process + +### Step 1 — Run the diff script + +```bash +bash ${CLAUDE_PLUGIN_ROOT:-.}/skills/scenario-doctor/scripts/diff-running-vs-intended.sh +``` + +Output is tab-separated, one row per service: + +``` +service port expected_sha actual_sha health status +platform 8080 08ab3a0aef27 08ab3a0aef27 200 MATCH +km1 8585 08ab3a0aef27 - down NOT-RUNNING +alpha 8181 v090... a1b2c3d4... 200 WRONG-BINARY +``` + +`status` enumerates: +- `MATCH` — expected ref matches the running binary's `.version` sha, health is 200. +- `WRONG-BINARY` — service is up but serving from a different ref than the instance pins. Often means a sibling worktree's environment is shadowing this one's expected binary. +- `NOT-RUNNING` — port is empty; `otdf-local --instance up` (or `restart `) is needed. +- `EXTRA` — port is occupied by a service the instance didn't declare. Usually a leftover from another instance/worktree. +- `NO-PIN` — instance manifest didn't pin this service (skip). + +### Step 2 — Verify instance-dir seed files + +`otdf-local instance init` is responsible for seeding `keys/{ca.jks,localhost.crt,localhost.key}`, `keys/kas-*.pem`, and `instances//opentdf.yaml` (with a generated `services.kas.root_key`). Confirm they're all present: + +```bash +bash ${CLAUDE_PLUGIN_ROOT:-.}/skills/scenario-doctor/scripts/check-instance-seed.sh +``` + +Tab-separated output, one row per artifact, `state ∈ {ok, missing, empty}`. Treat any non-`ok` row as a real problem — re-run `uv run otdf-local instance init --from-scenario ` to refresh (existing files are preserved, so this won't churn the root_key). + +### Step 3 — Assign a verdict + +Roll up Steps 1–2 into one of three colors. Lead the reply with the verdict; users scan for this. + +- **GREEN** — every declared service is `MATCH` + 200, no `EXTRA` rows, every seed file `ok`. Nothing for the user to do. +- **YELLOW** — at least one `WRONG-BINARY`, `EXTRA`, or `missing`/`empty` seed-file row, but the instance is *running*. Tests may pass or fail unpredictably until the drift is resolved. +- **RED** — at least one declared service is `NOT-RUNNING`. Tests cannot succeed; recommend `otdf-local --instance up` (fresh start) or per-service `restart`. + +### Step 4 — Per-row remedy + +For each non-`MATCH` row, emit a one-line remedy alongside the diff table: + +| Status | Remedy | +|---|---| +| `NOT-RUNNING` | `otdf-local --instance up` (full) or `restart ` (single service) | +| `WRONG-BINARY` | Identify owning PID's worktree via `lsof -p -d cwd`. If sibling worktree: tear that down first (`OTDF_LOCAL_INSTANCE_NAME= otdf-local down`). If same worktree, stale binary: `otdf-sdk-mgr install tip --ref platform` then restart. | +| `EXTRA` | Confirm the PID and its cwd. Stop owning instance or kill the stale PID. | +| `missing` / `empty` (seed file) | Re-run `otdf-local instance init --from-scenario `. Existing files are preserved; only the missing seed gets regenerated. | + +### Step 5 — Output + +Compose the reply in this order: verdict line, diff table (Step 1 output, lightly formatted), seed-file table (Step 2 output, only rows that aren't `ok`), per-row remedy bullets. Skip empty sections rather than print "(none)" — agents pattern-match on what's present. + +## When this skill triggers + +After any of: +- A surprising pytest result (skip when expected to pass, or pass when expected to skip-then-fail). +- The user asking "what's running" with the implication that they suspect drift, not a simple `instance ls` query (that's `instance-status`'s job). +- Returning to a long-lived branch where the running environment might be stale. + +For the simpler "what's defined / what's listening here" question without the diff-against-intent angle, defer to `instance-status`. + +## Limits + +- The script depends on the `.version` sidecar that `otdf-sdk-mgr install platform` writes. Binaries placed under `xtest/platform/dist/` by other means won't be diffable; they show as `expected_sha=?`. +- `yq` is preferred for parsing `instance.yaml`; the script falls back to grep when `yq` isn't installed. Coverage of the fallback is narrower — install `yq` for accurate KAS-list extraction in unusual manifests. +- Cross-worktree owner detection uses `lsof -p -d cwd`. Containers running services (rare today) wouldn't surface that way; the verdict would still flag the port collision via `EXTRA`, just without an owning-worktree label. + +## Additional Resources + +### Scripts + +- **`scripts/diff-running-vs-intended.sh`** — automates Step 1's expected-vs-actual diff. Takes one positional argument: the instance name. Tab-separated stdout. +- **`scripts/check-instance-seed.sh`** — read-only verifier for Step 2. Takes one positional argument: the instance name. Confirms `keys/{ca.jks,localhost.crt,localhost.key}`, `keys/kas-*.pem`, and `opentdf.yaml` (with a non-empty `services.kas.root_key`) are present in `tests/instances//`. Tab-separated stdout. + +### Reference files + +- **`references/probe-recipes.md`** — verbose shell snippets for ad-hoc inspection: resolving a PID to its worktree, comparing `.version` sidecars by hand, detecting Docker-created empty-dir stubs, listing compose-project owners. Read this when the script's output is ambiguous or the user wants the underlying mechanics. diff --git a/.claude/skills/scenario-doctor/references/probe-recipes.md b/.claude/skills/scenario-doctor/references/probe-recipes.md new file mode 100644 index 00000000..bcb5440b --- /dev/null +++ b/.claude/skills/scenario-doctor/references/probe-recipes.md @@ -0,0 +1,93 @@ +# Probe recipes + +Shell snippets the `scenario-doctor` skill uses (or recommends users run by hand) to inspect running services and compare against `instance.yaml` expectations. `scripts/diff-running-vs-intended.sh` automates the common path; reach for these recipes when the script's output needs deeper investigation or the agent has to answer an ad-hoc "what's actually running on port X?" question. + +## Identify what's listening on the conventional ports + +```bash +lsof -nP -iTCP:8080,8181,8282,8383,8484,8585,8686,5432,8888 -sTCP:LISTEN +``` + +Reads as `COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME`. The PID is what to chase next. + +## Resolve a PID to the binary path and its source worktree + +```bash +ps -o command= -p +# → /Users/.../tests/xtest/platform/dist//service start --config-file … +``` + +The binary lives at `…/dist//service`. Its sibling `.version` file records the source worktree and git SHA that built it: + +```bash +cat "$(dirname "$(ps -o command= -p | awk '{print $1}')")/.version" +# ref=refs/pull/3537/head +# sha=08ab3a0aef… +# worktree=/Users/.../DSPX-3302-02-platform-installer/tests/xtest/platform/src/refs--pull--3537--head +``` + +Whatever the `worktree=` line says is the directory the service binary loads keys / templates relative to — useful when investigating "platform started but says key X not found." + +## Resolve a PID to its cwd (often a different worktree than the agent) + +```bash +lsof -p -d cwd -Fn | awk '/^n/ { sub(/^n/,""); print; exit }' +``` + +A PID's cwd reveals which worktree initiated the service. Use this to spot cases where the agent thinks it's in worktree A but a sibling worktree B owns the running binary. + +## Compare expected ref to actual ref for an instance + +```bash +inst="tests/instances//instance.yaml" +yq -r '.platform.source.ref // .platform.dist' "$inst" # expected +ps -o command= -p "$(lsof -nP -iTCP:8080 -sTCP:LISTEN | awk 'NR>1 {print $2; exit}')" \ + | awk '{print $1}' | xargs -I{} cat "$(dirname {})/.version" # actual +``` + +Diff the two. Mismatch → either the instance is being served by a stale binary or by a binary from a different worktree. + +## Health pings + +```bash +curl -fsS http://localhost:8080/healthz # platform +curl -fsS http://localhost:8585/healthz # km1 +``` + +Returns `{"status":"SERVING"}` (HTTP 200) when healthy. Anything else is a real failure — check the corresponding log under `tests/instances//logs/`. + +## Confirm seed files exist (not Docker-created empty dirs) + +```bash +worktree="…/xtest/platform/src/" +for f in kas-private.pem kas-cert.pem kas-ec-private.pem kas-ec-cert.pem \ + keys/ca.jks keys/localhost.crt keys/localhost.key opentdf.yaml; do + if [[ -f "$worktree/$f" ]]; then + printf 'ok\t%s\n' "$f" + elif [[ -d "$worktree/$f" ]]; then + printf 'empty-dir\t%s\n' "$f" # Docker bind-mount left a stub directory + else + printf 'missing\t%s\n' "$f" + fi +done +``` + +`empty-dir` is the silent-failure shape: Docker auto-created the path as a directory because the source file didn't exist when compose first ran. Removing the stub and re-bootstrapping (via `scripts/bootstrap-pr-worktree.sh` or `init-temp-keys.sh`) is the fix. + +## Detect cross-worktree docker compose sharing + +```bash +docker ps --format '{{.Names}}' | grep -E -- '-keycloak-|-opentdfdb-' \ + | sed -E 's/-(keycloak|opentdfdb)-[0-9]+$//' | sort -u +``` + +Lists every compose-project name currently sharing the docker daemon. Each project is typically named after the directory `docker compose` was invoked from (i.e. a worktree's `xtest/platform/src//`). When multiple projects appear, `otdf-local --instance X down` will *not* stop docker — another instance is still using it. + +## Kill a stale platform/KAS process (use with care) + +```bash +pkill -9 -f "/dist//service start" # platform +pkill -9 -f "/dist//service kas start" # KAS +``` + +Prefer `otdf-local --instance down` when possible; `pkill` is the escape hatch when the instance owning the process doesn't match the worktree the agent is in (so `otdf-local` won't manage it cleanly). diff --git a/.claude/skills/scenario-doctor/scripts/check-instance-seed.sh b/.claude/skills/scenario-doctor/scripts/check-instance-seed.sh new file mode 100644 index 00000000..98b30f68 --- /dev/null +++ b/.claude/skills/scenario-doctor/scripts/check-instance-seed.sh @@ -0,0 +1,77 @@ +#!/usr/bin/env bash +# check-instance-seed.sh — read-only verifier that `otdf-local instance init` +# left the instance dir with the seed bundle `up` and pytest expect. +# +# Usage: check-instance-seed.sh +# +# `instance init` self-provisions: keys/{ca.jks,localhost.crt,localhost.key}, +# keys/kas-{private,cert,ec-private,ec-cert}.pem, and instances//opentdf.yaml +# with a generated services.kas.root_key. This script confirms each is present +# and reports tab-separated rows; it does not modify anything. +# +# Output: tab-separated, header on first line. +# Columns: artifact state detail +# state ∈ { ok | missing | empty } + +set -u + +if [[ $# -lt 1 ]]; then + echo "usage: $(basename "$0") " >&2 + exit 2 +fi + +name="$1" + +# Resolve repo root by walking up from $PWD until we find the tests/ marker. +dir="$PWD" +while [[ "$dir" != "/" && ! -d "$dir/instances" ]]; do dir="$(dirname "$dir")"; done +if [[ ! -d "$dir/instances" ]]; then + echo "could not locate tests/instances/ above $PWD" >&2 + exit 2 +fi +instance_dir="$dir/instances/$name" +if [[ ! -d "$instance_dir" ]]; then + echo "instance not found: $instance_dir" >&2 + exit 2 +fi + +REQUIRED_FILES=( + keys/ca.jks + keys/localhost.crt + keys/localhost.key + keys/kas-private.pem + keys/kas-cert.pem + keys/kas-ec-private.pem + keys/kas-ec-cert.pem + opentdf.yaml +) + +printf 'artifact\tstate\tdetail\n' + +for f in "${REQUIRED_FILES[@]}"; do + path="$instance_dir/$f" + if [[ ! -e "$path" ]]; then + printf '%s\tmissing\t-\n' "$f" + elif [[ -d "$path" ]]; then + printf '%s\tempty\tdirectory leftover (docker bind-mount stub)\n' "$f" + elif [[ ! -s "$path" ]]; then + printf '%s\tempty\tzero bytes\n' "$f" + else + printf '%s\tok\t-\n' "$f" + fi +done + +# Confirm the per-instance root_key got written into opentdf.yaml. +config="$instance_dir/opentdf.yaml" +if [[ -f "$config" ]]; then + if command -v yq >/dev/null 2>&1; then + rk="$(yq -r '.services.kas.root_key // ""' "$config" 2>/dev/null)" + else + rk="$(grep -E '^[[:space:]]*root_key:' "$config" 2>/dev/null | head -1 | sed -E 's/.*root_key:[[:space:]]*"?([^"[:space:]]+)"?.*/\1/')" + fi + if [[ -z "$rk" || "$rk" == "null" ]]; then + printf '%s\tmissing\troot_key empty in opentdf.yaml\n' "services.kas.root_key" + else + printf '%s\tok\t-\n' "services.kas.root_key" + fi +fi diff --git a/.claude/skills/scenario-doctor/scripts/diff-running-vs-intended.sh b/.claude/skills/scenario-doctor/scripts/diff-running-vs-intended.sh new file mode 100755 index 00000000..b7ff9f11 --- /dev/null +++ b/.claude/skills/scenario-doctor/scripts/diff-running-vs-intended.sh @@ -0,0 +1,150 @@ +#!/usr/bin/env bash +# diff-running-vs-intended.sh — verify that running services match what an +# instance.yaml claims they should be. +# +# Usage: diff-running-vs-intended.sh +# +# Walks the per-instance manifest at tests/instances//instance.yaml, +# resolves each pin (dist:/source.ref:) to its expected dist directory and +# git SHA via the .version sidecar, then compares against what's actually +# listening on the conventional ports. +# +# Output: tab-separated, header on first line. +# Columns: service port expected_sha actual_sha health status +# status ∈ { MATCH | WRONG-BINARY | NOT-RUNNING | EXTRA | NO-PIN } +# health ∈ { 200 | | down | - } + +set -u + +if [[ $# -lt 1 ]]; then + echo "usage: $(basename "$0") " >&2 + exit 2 +fi + +name="$1" + +# Resolve repo root by walking up from CWD until we find tests/instances/. +dir="$PWD" +while [[ "$dir" != "/" && ! -d "$dir/tests/instances" && ! -d "$dir/instances" ]]; do + dir="$(dirname "$dir")" +done +[[ -d "$dir/tests/instances" ]] && INST_ROOT="$dir/tests/instances" +[[ -d "$dir/instances" ]] && INST_ROOT="$dir/instances" +: "${INST_ROOT:?could not locate tests/instances/ above $PWD}" + +inst="$INST_ROOT/$name/instance.yaml" +[[ -f "$inst" ]] || { echo "no instance.yaml at $inst" >&2; exit 2; } + +PLATFORM_DIST="${INST_ROOT%/instances}/xtest/platform/dist" + +# Port map (matches otdf-local's Ports defaults). +declare -A PORT_OF=( + [platform]=8080 + [alpha]=8181 + [beta]=8282 + [gamma]=8383 + [delta]=8484 + [km1]=8585 + [km2]=8686 +) + +# Helper: resolve a pin (ref or dist) to expected_sha by reading .version. +expected_sha_for() { + local pin="$1" # could be a ref like 'main' or 'pr:3537', or a dist slug + local slug + for cand in "$PLATFORM_DIST"/*/; do + [[ -f "$cand/.version" ]] || continue + if grep -Fq "ref=$pin" "$cand/.version" \ + || grep -Fq "ref=refs/pull/${pin#pr:}/head" "$cand/.version" \ + || [[ "$(basename "${cand%/}")" == "$pin" ]]; then + awk -F= '/^sha=/ {print substr($2,1,12); exit}' "$cand/.version" + return + fi + done + echo "?" +} + +# Helper: actual_sha by inspecting the running binary at $port. +actual_sha_for_port() { + local port="$1" + local pid binary version + pid="$(lsof -nP -iTCP:"$port" -sTCP:LISTEN 2>/dev/null | awk 'NR>1 {print $2; exit}')" + [[ -z "$pid" ]] && { echo ""; return; } + binary="$(ps -o command= -p "$pid" 2>/dev/null | awk '{print $1}')" + [[ -f "$binary" ]] || { echo "?"; return; } + version="$(dirname "$binary")/.version" + [[ -f "$version" ]] && awk -F= '/^sha=/ {print substr($2,1,12); exit}' "$version" || echo "?" +} + +# Helper: http health code. +health_of() { + local port="$1" + curl -fsS -o /dev/null -w '%{http_code}' "http://localhost:$port/healthz" 2>/dev/null || echo down +} + +# Extract pins from instance.yaml. yq optional; fall back to grep. +get_pin() { + local field="$1" # e.g. .platform OR .kas.km1 + if command -v yq >/dev/null 2>&1; then + yq -r "($field.source.ref? // $field.dist? // \"\")" "$inst" + else + # Crude fallback: pull the first ref|dist under the section name. + awk -v sec="${field#.}" ' + $0 ~ "^"sec":" {f=1; next} + f && /^[^[:space:]]/ {f=0} + f && /(ref|dist):/ {gsub(/[",{}]/,""); for(i=1;i<=NF;i++) if($i ~ /^(ref|dist):/) {print $(i+1); exit}} + ' "$inst" + fi +} + +printf 'service\tport\texpected_sha\tactual_sha\thealth\tstatus\n' + +# Platform first. +pin="$(get_pin .platform)" +exp="$(expected_sha_for "$pin")" +act="$(actual_sha_for_port 8080)" +hc="$(health_of 8080)" +if [[ -z "$pin" ]]; then status=NO-PIN +elif [[ -z "$act" ]]; then status=NOT-RUNNING +elif [[ "$act" == "$exp" ]]; then status=MATCH +else status=WRONG-BINARY; fi +printf 'platform\t8080\t%s\t%s\t%s\t%s\n' "${exp:-?}" "${act:--}" "$hc" "$status" + +# KAS instances declared in the manifest. Build the list either via yq or +# the grep fallback. +kas_names=() +if command -v yq >/dev/null 2>&1; then + while IFS= read -r n; do kas_names+=("$n"); done < <(yq -r '.kas | keys[]' "$inst") +else + while IFS= read -r n; do kas_names+=("$n"); done < <( + awk '/^kas:/{f=1;next} f && /^[a-z0-9_-]+:/{gsub(":",""); print $1} f && /^[^[:space:]]/{f=0}' "$inst" + ) +fi + +for kas in "${kas_names[@]}"; do + port="${PORT_OF[$kas]:-?}" + pin="$(get_pin ".kas.$kas")" + exp="$(expected_sha_for "$pin")" + act="$(actual_sha_for_port "$port")" + hc="$([[ "$port" != "?" ]] && health_of "$port" || echo -)" + if [[ -z "$pin" ]]; then status=NO-PIN + elif [[ -z "$act" ]]; then status=NOT-RUNNING + elif [[ "$act" == "$exp" ]]; then status=MATCH + else status=WRONG-BINARY; fi + printf '%s\t%s\t%s\t%s\t%s\t%s\n' "$kas" "$port" "${exp:-?}" "${act:--}" "$hc" "$status" +done + +# Detect EXTRA services: any port in PORT_OF that's listening but wasn't +# declared in instance.yaml. +declared_ports=(8080) +for k in "${kas_names[@]}"; do declared_ports+=("${PORT_OF[$k]:-0}"); done +for svc in "${!PORT_OF[@]}"; do + port="${PORT_OF[$svc]}" + in_declared=0 + for d in "${declared_ports[@]}"; do [[ "$d" == "$port" ]] && in_declared=1 && break; done + [[ "$in_declared" == 1 ]] && continue + act="$(actual_sha_for_port "$port")" + [[ -z "$act" ]] && continue + hc="$(health_of "$port")" + printf '%s\t%s\t-\t%s\t%s\tEXTRA\n' "$svc" "$port" "$act" "$hc" +done diff --git a/.claude/skills/scenario-from-ticket/SKILL.md b/.claude/skills/scenario-from-ticket/SKILL.md new file mode 100644 index 00000000..8daff3da --- /dev/null +++ b/.claude/skills/scenario-from-ticket/SKILL.md @@ -0,0 +1,129 @@ +--- +name: scenario-from-ticket +description: This skill should be used when the user mentions a Jira key (e.g. "DSPX-3302") and asks to "create a scenario", "write a repro from the ticket", "make a TDD scenario", "draft a test for this bug", or otherwise turn a ticket into a `xtest/scenarios/.yaml` manifest plus (optionally) a draft pytest. Handles Bugs, Stories/Tasks (TDD), and Spikes via Issue Type. +allowed-tools: Bash, Read, Write, Grep, Glob +--- + +# scenario-from-ticket + +Produce a `xtest/scenarios/.yaml` manifest from a Jira ticket. The same skill handles bugs, features (TDD), and exploratory work — the *Issue Type* field on the ticket selects which way the rest of the skill behaves. + +Two artifacts: + +1. `xtest/scenarios/.yaml` — validated against `otdf_sdk_mgr.schema.Scenario`. +2. (Optional) `xtest/bugs/_test.py` — only if no existing xtest pytest already exercises the behavior. + +The Jira key also becomes the working **branch name** (`-repro` for Bugs, `-tdd` for Stories/Tasks) and the scenario file's `metadata.id`. + +## Step 1 — Pull the Jira ticket into context + +Run **both** commands — they take the key differently (`view` is positional, `comment list` requires `--key`). Don't skip the comment list; comments often carry the most recent reproduction status, "what changed" notes, or "fixed by PR #N" pointers that aren't in the original description: + +```bash +acli jira workitem view --fields '*all' --json +acli jira workitem comment list --key +``` + +From the JSON output of the first command, extract: + +- **Issue Type** (Bug, Story, Task, Spike) — load-bearing; selects which Step 2 branch to follow. +- **Summary** — becomes scenario `metadata.title`. +- **Description** — version numbers, KAS topology, container types, feature flags, acceptance criteria typically live here. +- **Status** — Backlog / In Progress / Done affects whether the scenario is forward-looking (TDD on Backlog) or retroactive (regression gate on Done). + +From the comments, pull any "tested at version X" / "reproduces on platform Y" / "fixed by PR #N" annotations into context. + +If the ticket references attached logs, screenshots, or linked PRs, list them: + +```bash +acli jira workitem attachment list +acli jira workitem link list +``` + +**Linked-PR auto-pin.** When `link list` returns a PR URL (e.g. `https://github.com/opentdf/platform/pull/3537`), resolve it immediately and prefer it over the headless default `dist: lts`: + +```bash +gh pr view --repo --json number,headRefName,headRefOid +``` + +Use the 40-char `headRefOid` as `source.ref:` for the platform/KAS pin. Branch names move on every push; SHAs don't. Record the branch name in `metadata.title` for human readability. See `references/yaml-templates.md` → "PR pin via Jira link" for the full template. + +**Permitted Jira writes**: only `acli jira workitem comment create ...` (to post a reproduction-status update if the user asks). Everything else — `edit`, `transition`, `assign`, `archive`, `delete`, `link create`, `watcher add` — is explicitly disallowed by the plugin's permissions; if the user wants those actions, instruct them to run the command. + +## Step 2 — Branch on Issue Type + +### Bug + +The ticket describes a behavior that should work but doesn't. + +- `expected:` — what should happen (copy from the description's "expected behavior" section or rephrase the summary). +- `actual:` — what actually happens, including the exact error message if the ticket quotes one. +- Pin platform / KAS / SDKs to the **versions where the bug reproduces**. Usually `dist:` against a released version. Mixed-version topologies (e.g. platform `v0.9.0` + km1 `v0.9.0-rc.2`) are common and the schema supports them. + +If the description doesn't name versions: prefer a linked PR (from Step 1) if any; otherwise ask the user. A headless agent with no PR and no version pin defaults to `dist: lts` and calls out the assumption in `actual:`. + +### Story / Task (feature work, TDD-style) + +The ticket describes a behavior the user wants to *add*. The scenario is a forward-looking regression gate, not a bug reproducer. + +- `expected:` — the new behavior, paraphrased from acceptance criteria. +- `actual:` — current state, e.g. "feature not implemented; tests skip via `.supports('')` until the supports entry lands." `scenario-run`'s "expected outcome" classifier compares against this — a real failure means progress; a uniform skip means the prereq SDK plumbing is still pending. +- Pin platform / KAS / SDKs to the **ref where the feature will land**: linked PR (from Step 1) if any, else HEAD of mainline (`source: { ref: main }`), else a feature branch the user names. Only pin components the feature actually touches; leave the rest on `lts` / `stable`. + +### Spike / unclear + +The ticket asks an open question or lacks enough concrete behavior to encode. Don't fabricate. Emit: + +``` + is a Spike (or has no specific behavior / version pins yet). Add either: + (a) the version or ref where you want behavior exercised, or + (b) a concrete pass/fail criterion (what should the test assert?) +…and re-invoke this skill. +``` + +…and stop. + +## Step 3 — Pick the id and (optionally) the branch + +- `metadata.id = ` — e.g. `DSPX-3302` → `dspx-3302`. +- Scenario file path: `xtest/scenarios/.yaml`. +- If a new git branch is needed, propose `-repro` for Bugs and `-tdd` for Stories/Tasks; let the user confirm before switching. + +## Step 4 — Search for an existing pytest + +```bash +grep -rn "" xtest/test_*.py xtest/tdfs.py +``` + +Likely candidates: `test_tdfs.py` (roundtrip), `test_abac.py` (ABAC), `test_legacy.py` (golden), `test_pqc.py`. If a test already asserts the relevant behavior, reuse it via `suite.targets` (list of pytest selectors) — no draft test needed. + +**Don't grep `xtest/sdk//cli.sh`.** Those wrappers are reusable infrastructure (versioned alongside each SDK dist) and their contents have nothing to do with scenario YAML fields. The scenario doesn't need to know HOW a feature is plumbed — only WHICH pytest suite exercises it. If a feature's `supports("")` gate isn't in `tdfs.py` yet, that's a signal that supporting infrastructure has to land separately from the scenario — note it in `actual:` and move on. + +## Step 5 — Write `xtest/scenarios/.yaml` + +Templates (released-version, ref-pin, mixed-mode, PR-pin-via-Jira-link) live in **`references/yaml-templates.md`**. Pick the matching shape, copy, and fill in. + +Validate before reporting success: + +```bash +uv run python -m otdf_sdk_mgr.schema validate xtest/scenarios/.yaml +``` + +## Step 6 — If no existing test fits + +Draft `xtest/bugs/_test.py` using the `encrypt_sdk` / `decrypt_sdk` fixtures (pattern: `xtest/test_tdfs.py`). Surface the new file in the reply for the user to review — never silently land assertions. + +For TDD tests where the underlying feature isn't yet implemented, gate participation behind `.supports("")` and call `pytest.skip(...)` when the gate fails. The scenario then runs as "all skipped" until the SDK supports entry lands. + +## Notes + +- `sdks.encrypt` and `sdks.decrypt` map to xtest's `--sdks-encrypt` / `--sdks-decrypt`. Pytest options take `sdk@version` specifiers (e.g. `go@v0.24.0`). **Do NOT write those tokens in the YAML** — write a normal `{ version: lts }` (or any version string `otdf-sdk-mgr resolve` accepts). `scenario-up` runs `otdf-sdk-mgr install scenario`, which records the resolved dist names in `xtest/scenarios/.installed.json`; the bridge layers read that file to emit the right `sdk@` tokens. +- List the same SDK in both `encrypt` and `decrypt` maps to reproduce xtest's legacy "all pairs" mode. Listing it on only one side keeps the scenario focused (a→b without b→a). +- For matrix runs (same suite × N refs), don't author N scenarios by hand — invoke the `scenario-matrix` skill against this scenario as the base. +- Hand the resulting scenario to `scenario-up` next. + +## Additional Resources + +### Reference files + +- **`references/yaml-templates.md`** — every scenario YAML shape: released-version (Bug), ref-pin (TDD/HEAD), mixed-mode (new platform + shipped KAS), PR-pin-via-Jira-link (recommended when `acli link list` returned an opentdf PR), plus the validation command. Read this when writing or reviewing a scenario manifest. diff --git a/.claude/skills/scenario-from-ticket/references/yaml-templates.md b/.claude/skills/scenario-from-ticket/references/yaml-templates.md new file mode 100644 index 00000000..24b2640d --- /dev/null +++ b/.claude/skills/scenario-from-ticket/references/yaml-templates.md @@ -0,0 +1,96 @@ +# Scenario YAML templates + +The canonical field list (titles, types, defaults, `anyOf` branches) lives in `xtest/schema/scenario.schema.json`. Read it whenever a question about an allowed field arises. Each pin (`PlatformPin`, `KasPin`) requires **exactly one** of `dist:`, `source:`, or `image:`. `image:` is reserved for forward-compat and is rejected today — pick `dist:` or `source:`. + +## Released-version pin (typical Bug scenario) + +Use when reproducing a bug on a published release. + +```yaml +apiVersion: opentdf.io/v1alpha1 +kind: Scenario +metadata: + id: + title: "" + created: +instance: + metadata: { name: } + platform: { dist: v0.9.0 } + ports: { base: } + kas: + alpha: { dist: v0.9.0, mode: standard } +sdks: + encrypt: + go: { version: lts } + decrypt: + java: { version: "0.7.8" } +suite: + select: "xtest/test_tdfs.py::test_tdf_roundtrip" + containers: ztdf +expected: "..." +actual: "..." +``` + +## Ref pin (TDD / HEAD / branch / PR) + +Use when the behavior under test lives on an unreleased branch, an in-flight PR, or HEAD. For PRs, prefer the 40-char `headRefOid` from `gh pr view --json headRefOid` over the branch name — SHAs are immutable, branches move. + +```yaml +instance: + platform: + source: { ref: main } # branch, tag, 40-char SHA, or pr:N + kas: + alpha: + source: { ref: feature/ecdsa-binding } + mode: standard +sdks: + encrypt: + go: { version: main } # SdkPin.version accepts the same range of strings +``` + +## Mixed-mode (platform on a ref, KAS on a release) + +Use when validating that an unreleased platform interoperates with shipped KAS deployments (or vice versa). + +```yaml +instance: + platform: + source: { ref: pr:3537 } # in-flight PR + kas: + alpha: { dist: v0.9.0, mode: standard } # shipped KAS + km1: + source: { ref: pr:3537 } # KAS that needs PR changes + mode: key_management +sdks: + encrypt: { go: { version: main } } + decrypt: { go: { version: lts } } # old client decrypting new platform output +``` + +## PR pin via Jira link (recommended for Story/Task tickets) + +When `acli jira workitem link list ` returned a linked PR (URL like `github.com/opentdf/platform/pull/`), resolve and pin to the head SHA: + +```bash +gh pr view --repo opentdf/platform --json number,headRefName,headRefOid +# → { "number": 3537, "headRefName": "DSPX-3383-post-quantum-kem", "headRefOid": "08ab3a0a…" } +``` + +Then in the scenario: + +```yaml +metadata: + title: " [opentdf/platform#3537 @ DSPX-3383-post-quantum-kem]" +instance: + platform: + source: { ref: 08ab3a0a... } # immutable 40-char SHA +``` + +Record the branch name in `metadata.title` for human readability; the SHA is what `otdf-sdk-mgr install` uses. + +## Validation + +Always validate before reporting success: + +```bash +uv run python -m otdf_sdk_mgr.schema validate xtest/scenarios/.yaml +``` diff --git a/.claude/skills/scenario-matrix/SKILL.md b/.claude/skills/scenario-matrix/SKILL.md new file mode 100644 index 00000000..b5e23953 --- /dev/null +++ b/.claude/skills/scenario-matrix/SKILL.md @@ -0,0 +1,104 @@ +--- +name: scenario-matrix +description: This skill should be used when the user asks to "run the same suite across multiple versions", "bisect a regression across releases", "validate a fix across PRs", "generate a scenario matrix", or wants the same test suite exercised at N different platform / SDK refs. Generates scenario files only; does not run them — hand the output to `scenario-up` / `scenario-run` per cell. +allowed-tools: Bash, Read, Write, Grep, Glob +--- + +# scenario-matrix + +Produce N scenario files from one base scenario, where N is the number of refs the user wants exercised. Each output scenario differs only in `instance.platform` (and optionally any KAS pins the user says should track the same ref). SDK pins are preserved unless explicitly told to vary. + +## Inputs + +- A **base**, either: + - Path to an existing `xtest/scenarios/.yaml`, OR + - A Jira ticket key — invoke `scenario-from-ticket` first to produce the base, then proceed. +- A **ref list** — any combination of: + - Released versions: `v0.9.0`, `v0.8.5` + - Branch names: `main`, `feature/ecdsa-binding` + - PR numbers: `1234`, `1235` (resolved to head SHAs for reproducibility) +- (Optional) which KAS instances should track the same ref as `platform`. Default: every KAS instance in the base also tracks the ref. + +## Process + +### Step 1 — Resolve the base scenario + +- If given a path: `Read` it. +- If given a ticket key: invoke `scenario-from-ticket` against the ticket first, then `Read` the produced file. + +The base scenario provides everything except `instance.platform` (and tracked KAS pins): `metadata.title` becomes the title prefix, `suite` is shared across all cells, `sdks` is preserved. + +### Step 2 — Resolve each ref to a concrete value + +- Released version → use verbatim under `dist:`. Example: `v0.9.0` → `platform: { dist: v0.9.0 }`. +- Branch name → use under `source.ref:`. Example: `main` → `platform: { source: { ref: main } }`. +- PR number `N` → fetch: + + ```bash + gh pr view --json number,headRefName,headRefOid + ``` + + …and pin under `source.ref:` to the **`headRefOid`** (40-char SHA), **not** `headRefName`. Reason: branch names move on every push, SHAs don't. Record `headRefName` in the scenario title for human readability. + +### Step 3 — Emit one scenario file per ref + +Naming: `xtest/scenarios/-.yaml`. Tokens: + +- Released version: strip `v` and dots — `v0.9.0` → `v090`. +- Branch: replace `/` with `-` — `feature/ecdsa-binding` → `feature-ecdsa-binding`. +- PR: `pr` — `1234` → `pr1234`. The SHA still lives inside the file. + +Each cell scenario gets: + +- A unique `metadata.id` (`-`) matching the file basename. +- A unique `instance.metadata.name` (same as `metadata.id`). +- A unique `instance.ports.base` — start from the base's value and add `+1000` per additional cell. `scenario-up` rejects overlapping port bases between concurrent instances. +- `metadata.title` gets a ` []` suffix for at-a-glance identification. +- `instance.platform` rewritten to the resolved ref. For KAS pins that should track the same ref (default: all of them), rewrite their pin too. Pins the user explicitly excluded keep the base's value. +- `suite`, `sdks`, `expected`, `actual` — unchanged from the base. + +### Step 4 — Validate every file + +```bash +for f in xtest/scenarios/-*.yaml; do + uv run python -m otdf_sdk_mgr.schema validate "$f" +done +``` + +Bail (delete the just-written files) if any cell fails validation — partial matrices are confusing. + +### Step 5 — Report + +- The list of files written. +- The exact `scenario-up` / `scenario-run` chain the user can run per cell (or in a loop): + + ```bash + for f in xtest/scenarios/-*.yaml; do + name="$(basename "$f" .yaml)" + uv run otdf-sdk-mgr install scenario "$f" + uv run otdf-local instance init "$name" --from-scenario "$f" + uv run otdf-local --instance "$name" up + uv run otdf-local scenario run --instance "$name" "$f" + uv run otdf-local --instance "$name" down + done + ``` + +## Notes + +- This skill **writes scenario files only**. It does not install artifacts, scaffold instances, or run pytest. Hand the resulting files to `scenario-up` and `scenario-run` per cell. +- For two PRs that differ in *SDK* (not platform), vary `sdks...version` instead of `platform`. Same pattern, different field — `SdkPin.version` accepts the same range of refs (`v0.24.0`, `main`, SHA). +- For a full platform × SDK matrix, generate N×M scenarios. Be prepared for long install times — each new platform ref triggers a `go build` (~30–60s first time per version); subsequent runs reuse the cached binary. +- Don't update `expected:` / `actual:` per cell unless the user specifies that one of the refs is the "known good" or "known broken" baseline. + +### Pre-install shared refs (workaround for [DSPX-3417](https://virtru.atlassian.net/browse/DSPX-3417)) + +`otdf-sdk-mgr install scenario` currently rebuilds the platform once per pin even when N pins share a ref — so an N-cell matrix on the same platform ref triggers N rebuilds, each ~30–60s. Workaround: + +```bash +# Build once. +uv run otdf-sdk-mgr install tip --ref platform +# Then run the per-cell loop in Step 5; each `install scenario` will reuse +# the cached binary instead of rebuilding. +``` + +When DSPX-3417's dedup ships, the workaround becomes unnecessary. diff --git a/.claude/skills/scenario-run/SKILL.md b/.claude/skills/scenario-run/SKILL.md new file mode 100644 index 00000000..e533145b --- /dev/null +++ b/.claude/skills/scenario-run/SKILL.md @@ -0,0 +1,87 @@ +--- +name: scenario-run +description: This skill should be used when the user asks to "run the scenario", "run the scenario tests", "execute the scenario suite", "test the scenario", or after `scenario-up` to invoke the pytest selection declared by `xtest/scenarios/.yaml` and classify the result against the scenario's `expected:` / `actual:` fields. +allowed-tools: Bash, Read +--- + +# scenario-run + +Invoke the pytest selection declared by the scenario's `suite` block against the running instance, then classify the result in terms of the ticket the scenario was authored for. The same four-bucket classification works for bug-repros (where "expected" means *failure that matches `actual:`*), TDD scenarios (where "expected" means *skip-until-feature-lands*), and assertion drift between draft tests and what the implementation actually emits. + +## Inputs + +- Path to the scenario YAML (`xtest/scenarios/.yaml`). +- (Optional) the user's expected outcome, if the scenario's `expected:` field is sparse. + +## Process + +### Step 1 — Invoke the runner + +```bash +uv run otdf-local scenario run --instance xtest/scenarios/.yaml +``` + +This translates the scenario's `suite.targets` (list — each entry becomes a positional pytest arg), `suite.containers` (list — joined into a single whitespace-separated `--containers` value), `suite.kexpr`, `suite.markers`, and `sdks.{encrypt,decrypt}` into the equivalent `pytest --sdks-encrypt … --sdks-decrypt … --containers …` invocation under `xtest/` with `OTDF_LOCAL_INSTANCE_NAME` set. SDK tokens are emitted in xtest's `sdk@version` form; the resolved version names come from the sibling `.installed.json`. + +Failure modes: +- `Error: .installed.json not found` — the user skipped Step 1 of `scenario-up`. Run `uv run otdf-sdk-mgr install scenario ` first. +- `installed.json` is present but `sdks.encrypt` / `sdks.decrypt` are empty arrays despite the scenario declaring SDK pins — this is the **source-built SDK** case; fall back to a direct pytest invocation (see Step 1b). + +### Step 1b — Source-build fallback + +When the scenario pins source-built SDKs (`source.ref` rather than `version`), `otdf-local scenario run` today produces an empty `--sdks-*` argv. Invoke pytest directly instead: + +```bash +cd xtest +set -a +eval "$(cd ../otdf-local && OTDF_LOCAL_INSTANCE_NAME= uv run otdf-local env)" +source test.env +set +a + +# Map each source-pinned SDK to its dist slug under xtest/sdk//dist/. +# For platform PR #N, the slug is typically `refs--pull----head`. +PLATFORM_VERSION= OTDFCTL_HEADS='[""]' \ + uv run pytest \ + --sdks-encrypt @ \ + --sdks-decrypt @ \ + --containers "" +``` + +`PLATFORM_VERSION` and `OTDFCTL_HEADS` defaults are noted in `scenario-up`; pull them from there or from the scenario's source-build env knobs section. This fallback is temporary — tracked at [DSPX-3417](https://virtru.atlassian.net/browse/DSPX-3417) (scenario YAML accepting source builds) and [DSPX-3418](https://virtru.atlassian.net/browse/DSPX-3418) (`OTDFCTL_HEADS` → CLI flag). + +### Step 2 — Capture exit code and tail of output + +The pytest output is the source of truth; do not re-interpret it. Save the last ~60 lines for the evidence quote in the classification. + +### Step 3 — Classify against `expected:` and `actual:` + +Pick exactly one bucket. Lead the reply with the bucket name; users skim for it. + +- **Expected outcome** — the test result matches what `expected:` (or, for a bug, `actual:`) predicts. + - Bug scenario: pytest FAILED with an assertion or stderr matching `actual:`. Bug reproduced; cite the matching line. + - TDD/feature scenario on a ref where the feature isn't landed: tests SKIPPED via `supports("")`. Gate still pending as predicted. + - TDD/feature scenario on a ref where the feature is landed: tests PASSED. The scenario is now a regression gate. + +- **Unexpected outcome** — the test result is *not* what the scenario predicted. + - Bug scenario: pytest PASSED. Either the bug is fixed at this pin, or the scenario doesn't capture it tightly enough. Suggest widening the assertion, pinning a different ref, or closing the bug. + - TDD/feature scenario: tests FAILED for a reason that doesn't match `actual:`. A real bug surfaced, OR the prereq implementation landed and the test now needs a real assertion rather than a skip. + +- **Assertion-stricter-than-implementation** — pytest FAILED on a specific assertion whose expected value is *aspirational* (drawn from a PR description, spec, or RFC) rather than current behaviour. Diagnostic: one assertion compares a single real field to a single concrete value, both legitimate, and they simply don't match. The implementation works correctly under a *different* contract than the test encodes. Action: relax the assertion to the observed value (record both old and new in a comment so the intent is preserved), file a follow-up if the strict value is load-bearing. This is what catches "PR description said KAO type is `mlkem-wrapped` but the binary emits `wrapped`." + +- **Unrelated failure** — pytest errored out (collection error, environment issue, import error, timeout). Don't claim outcome match either way; report the error and recommend a next diagnostic step. If services look wrong, defer to `scenario-doctor` for a state diff. + +### Step 4 — Record artifacts + +Pytest leaves logs under `tests/instances//logs/`. List the relevant per-service log paths in the reply so the user can attach them to the Jira ticket. + +## Output format + +One-line headline naming the bucket, then a short bulleted summary: +- `targets:` the pytest selectors that ran (one per `suite.targets` entry) +- `exit_code:` the pytest return value +- `evidence:` 1–2 lines from the output that justify the classification +- `logs:` paths to the relevant per-service logs + +## When to defer + +If the failure looks environmental (services missing, ports drift, stale binary) rather than test-substantive, hand off to `scenario-doctor` for a state-vs-intent diff before iterating on the test or scenario. diff --git a/.claude/skills/scenario-tear-down/SKILL.md b/.claude/skills/scenario-tear-down/SKILL.md new file mode 100644 index 00000000..a37b5fbc --- /dev/null +++ b/.claude/skills/scenario-tear-down/SKILL.md @@ -0,0 +1,78 @@ +--- +name: scenario-tear-down +description: This skill should be used when the user asks to "tear down the scenario", "stop the instance", "shut down the test environment", "clean up the scenario", "free the ports", or is done with a scenario and wants services stopped and (optionally) on-disk state removed. +allowed-tools: Bash, Read +--- + +# scenario-tear-down + +Stop a running scenario cleanly and optionally remove its on-disk state. Confirm shared resources (docker stacks across worktrees, symlinked platform dirs) are handled appropriately. + +## Inputs + +- The instance name (typically the lowercased Jira key, e.g. `dspx-3302`). If the user passed the scenario YAML path instead, read its `instance.metadata.name`. +- Whether to preserve the instance directory (default: yes — keep it for re-runs). + +## Process + +### Step 1 — Pre-flight shared resources + +Before stopping anything, list the docker compose projects currently sharing the host daemon: + +```bash +docker ps --format '{{.Names}}' \ + | grep -E -- '-keycloak-|-opentdfdb-' \ + | sed -E 's/-(keycloak|opentdfdb)-[0-9]+$//' \ + | sort -u +``` + +Each line is a compose-project name — typically the directory name where `docker compose` was invoked (a worktree's `xtest/platform/src//`). If more than one project appears, surface this in the reply: `down` will *keep* docker keycloak/postgres running because another instance still uses them. The user's expectation that "ports 5432 and 8888 are now free" would be wrong. + +### Step 2 — Stop services + +```bash +uv run otdf-local --instance down +``` + +Halts the platform process, all KAS instances under management, and the docker dependencies — unless another instance is still using them, in which case docker is left running (per Step 1's pre-flight). Other instances' platforms and KAS processes are untouched. + +### Step 3 — Optionally clean state + +Only if the user explicitly asked to remove: + +```bash +uv run otdf-local instance rm -y +``` + +Deletes `tests/instances//` including its `logs/`, `keys/`, and per-KAS configs. The platform binary at `xtest/platform/dist//service` is shared and is NOT removed. To free those too: + +```bash +uv run otdf-sdk-mgr clean --dist-only +``` + +### Step 4 — Confirm + +```bash +uv run otdf-local instance ls --json +``` + +Verify the instance is gone (if `rm`'d) or that its services no longer appear running. If sibling worktrees still own ports, that's recorded in Step 1's output — flag it in the summary. + +## Post-down notes to surface + +- **Symlinked platform dir**: if this worktree's `xtest/platform` is a symlink (or `xtest/platform.local-backup/` exists), mention it. That was a one-time workaround for `uv tool install`'d CLIs anchoring to a sibling worktree (see DSPX-3415). The backup directory accumulates stale `src/` and can be reclaimed (`rm -rf xtest/platform.local-backup`) once the user is sure the symlink is permanent. +- **Foreign docker-compose project**: if Step 1 surfaced another project, name it so the user knows which worktree to manage if they want a truly clean host. + +## Caution + +Never remove an instance without explicit user confirmation. The directory may contain golden keys or generated configs that took time to assemble. If unsure, leave it. + +## Output + +One-line summary, then optional sections in this order: +- Stop result (services stopped: …). +- Cleaned (if `rm` was run): instance dir removed at … +- Docker status: stopped / still running (with project names if shared). +- Post-down notes (symlinks, backup dirs, foreign projects). + +Skip empty sections. diff --git a/.claude/skills/scenario-up/SKILL.md b/.claude/skills/scenario-up/SKILL.md new file mode 100644 index 00000000..ebbe9f26 --- /dev/null +++ b/.claude/skills/scenario-up/SKILL.md @@ -0,0 +1,92 @@ +--- +name: scenario-up +description: This skill should be used when the user asks to "bring up a scenario", "start a scenario environment", "spin up the test instance", "install and run the scenario", or has authored a `xtest/scenarios/.yaml` and wants the platform + KAS + dependencies started before invoking pytest. Use `scenario-run` after this succeeds. +allowed-tools: Bash, Read +--- + +# scenario-up + +Bring the environment described by a `xtest/scenarios/.yaml` up and confirm it is healthy. The four steps are non-negotiable; do them in order. + +## Inputs + +- Path to a validated `xtest/scenarios/.yaml`. If the user did not provide one, ask. + +## Process + +### Step 1 — Install artifacts + +```bash +uv run otdf-sdk-mgr install scenario xtest/scenarios/.yaml +``` + +Installs the platform binary, per-KAS binaries, helper scripts, and the encrypt + decrypt SDKs declared in the scenario. The result is recorded at `xtest/scenarios/.installed.json` next to the scenario. + +**Guard against partial installs.** Read the resulting `.installed.json` immediately: + +```bash +cat xtest/scenarios/.installed.json | jq '{status, sdk_count: (.sdks.encrypt + .sdks.decrypt | length)}' +``` + +If `status == "partial"` OR `sdks.encrypt` / `sdks.decrypt` are empty arrays *but* the scenario declared SDK entries, treat it as a hard failure and stop. Today `install scenario` silently ignores source-built SDK pins (only released versions resolve via `install_release`). The remedy: + +```bash +# Install source-built SDKs separately, then continue. +uv run otdf-sdk-mgr install tip --ref +``` + +This limitation is tracked at [DSPX-3417](https://virtru.atlassian.net/browse/DSPX-3417). When that ships, the guard becomes redundant — keep it until then. + +First `go build` per platform version takes ~30–60s; subsequent runs reuse the cached binary. + +### Step 2 — Scaffold the instance directory + +```bash +uv run otdf-local instance init --from-scenario xtest/scenarios/.yaml +``` + +Creates `tests/instances//` and **self-provisions the bootstrap bundle**: generates the Keycloak TLS pair + `keys/ca.jks` truststore, creates `kas-*.pem` keys, and copies the platform's `opentdf-dev.yaml` (or `opentdf-example.yaml`) into `instances//opentdf.yaml` with a freshly generated `services.kas.root_key`. Idempotent — existing files are preserved, so the per-instance root key survives re-runs. Double-check with `uv run otdf-local instance ls` first to avoid surprising the user with overwrites. + +### Step 3 — Bring it up + +```bash +uv run otdf-local --instance up +``` + +Then poll status until everything is healthy (do not proceed before this succeeds): + +```bash +uv run otdf-local --instance status --json +``` + +If any service stays unhealthy after ~60 seconds, surface the relevant log via `uv run otdf-local --instance logs -n 50` and report the failure mode rather than retrying blindly. + +Once healthy, sanity-check the env exports `scenario-run` will rely on: + +```bash +uv run otdf-local --instance env --format json | jq '{PLATFORM_DIR,PLATFORMURL,SCHEMA_FILE,OT_ROOT_KEY}' +``` + +All four must be non-null. If `OT_ROOT_KEY` is null, the instance's `opentdf.yaml` is missing or didn't get a `services.kas.root_key` written (re-run `instance init` to refresh). + +## Source-build env knobs + +When the scenario pins source-built artifacts (`source.ref` on platform / KAS / SDKs), two env-var overrides are temporarily required for `scenario-run`. Note them now so the user has them ready: + +```bash +# Tell xtest which otdfctl binary to use (the slug under xtest/sdk/go/dist/). +export OTDFCTL_HEADS='["refs--pull----head"]' + +# Make tdfs.get_platform_features() enable in-flight feature flags whose semver +# gate is in the future; PR builds self-report old versions. +export PLATFORM_VERSION=0.17.0 +``` + +These workarounds are tracked at [DSPX-3418](https://virtru.atlassian.net/browse/DSPX-3418) (`OTDFCTL_HEADS` → CLI flag) and [DSPX-3419](https://virtru.atlassian.net/browse/DSPX-3419) (auto-derive `PLATFORM_VERSION`). When either lands, remove the corresponding line. + +## Output + +Once healthy, report: +- The instance name and which ports it occupies (look at `instance.yaml`'s `ports.base`). +- The path to `.installed.json` (so `scenario-run` can find it). +- The next command the user is likely to run: `scenario-run xtest/scenarios/.yaml`. diff --git a/otdf-sdk-mgr/src/otdf_sdk_mgr/cli.py b/otdf-sdk-mgr/src/otdf_sdk_mgr/cli.py index 24148bdd..78b137c9 100644 --- a/otdf-sdk-mgr/src/otdf_sdk_mgr/cli.py +++ b/otdf-sdk-mgr/src/otdf_sdk_mgr/cli.py @@ -10,6 +10,7 @@ import typer from otdf_sdk_mgr.cli_install import install_app +from otdf_sdk_mgr.cli_schema import schema_app from otdf_sdk_mgr.cli_versions import versions_app from otdf_sdk_mgr.config import ALL_SDKS, get_sdk_dirs @@ -20,6 +21,7 @@ ) app.add_typer(install_app, name="install") +app.add_typer(schema_app, name="schema") app.add_typer(versions_app, name="versions") diff --git a/otdf-sdk-mgr/src/otdf_sdk_mgr/cli_schema.py b/otdf-sdk-mgr/src/otdf_sdk_mgr/cli_schema.py new file mode 100644 index 00000000..b3fb17b7 --- /dev/null +++ b/otdf-sdk-mgr/src/otdf_sdk_mgr/cli_schema.py @@ -0,0 +1,57 @@ +"""`otdf-sdk-mgr schema` subcommands. + +Emit canonical JSON Schemas for the Pydantic models in `otdf_sdk_mgr.schema` +so agents (and humans) can introspect the on-disk YAML formats without +running `python -c` against the package. The generated files live under +`xtest/schema/` and are kept in sync via `tests/test_schema_sync.py`. +""" + +from __future__ import annotations + +import json +from pathlib import Path +from typing import Annotated + +import typer +from otdf_sdk_mgr.schema import Instance, Scenario + +schema_app = typer.Typer(help="Emit JSON Schemas for the scenario/instance models.") + +# (model_class, output_filename). Add new models here and `schema dump` +# will pick them up automatically. +SCHEMAS: tuple[tuple[type, str], ...] = ( + (Scenario, "scenario.schema.json"), + (Instance, "instance.schema.json"), +) + + +def render(model: type) -> str: + """Render `model.model_json_schema()` as a deterministic JSON string. + + Sorted keys and a trailing newline so byte-equality comparisons in the + sync test are stable. + """ + return json.dumps(model.model_json_schema(), indent=2, sort_keys=True) + "\n" + + +@schema_app.command("dump") +def dump( + out_dir: Annotated[ + Path, + typer.Option( + "--out-dir", + help="Directory to write *.schema.json files into.", + ), + ] = Path("xtest/schema"), +) -> None: + """Write JSON Schemas for every canonical scenario/instance model. + + Overwrites existing files. Re-run whenever a Pydantic model changes; + the committed schemas in xtest/schema/ are otherwise the source of + truth that the scenario-authoring skills read. + """ + out_dir.mkdir(parents=True, exist_ok=True) + for model, filename in SCHEMAS: + path = out_dir / filename + path.write_text(render(model), encoding="utf-8") + typer.echo(f" wrote {path}") diff --git a/otdf-sdk-mgr/tests/test_schema_sync.py b/otdf-sdk-mgr/tests/test_schema_sync.py new file mode 100644 index 00000000..addeaf8a --- /dev/null +++ b/otdf-sdk-mgr/tests/test_schema_sync.py @@ -0,0 +1,38 @@ +"""Guard that the committed JSON Schemas under xtest/schema/ stay in sync +with the live Pydantic models. + +The skills authoring scenarios read those JSON files directly to know what +fields are allowed; if a Pydantic model gains, loses, or renames a field +without a corresponding `uv run otdf-sdk-mgr schema dump`, the skills will +silently rely on a stale schema. This test makes that drift loud. +""" + +from __future__ import annotations + +from pathlib import Path + +import pytest +from otdf_sdk_mgr.cli_schema import SCHEMAS, render + + +def _xtest_schema_dir() -> Path: + """Locate xtest/schema/ relative to this test file. + + The repo layout puts otdf-sdk-mgr/tests/ next to xtest/, so two parents + up from this file is the tests/ root. + """ + return Path(__file__).resolve().parents[2] / "xtest" / "schema" + + +@pytest.mark.parametrize(("model", "filename"), SCHEMAS, ids=lambda v: getattr(v, "__name__", v)) +def test_committed_schema_matches_model(model: type, filename: str) -> None: + path = _xtest_schema_dir() / filename + assert path.is_file(), ( + f"Missing {path}. Run `uv run otdf-sdk-mgr schema dump` to regenerate." + ) + expected = render(model) + actual = path.read_text(encoding="utf-8") + assert actual == expected, ( + f"{path} is out of sync with {model.__name__}. " + f"Run `uv run otdf-sdk-mgr schema dump` to regenerate." + ) diff --git a/xtest/README.md b/xtest/README.md index 6bdfcc40..0c7400fa 100644 --- a/xtest/README.md +++ b/xtest/README.md @@ -122,3 +122,11 @@ pytest rm -rf tmp pytest test_tdfs.py ``` + +## Test artifact directories + +- **`scenarios/`** — Per-ticket scenario YAMLs that pin a platform / KAS / SDK topology to a specific pytest selection. Consumed by `otdf-local scenario run`. +- **`features/`** — Multi-repo feature specs: features that touch more than one OpenTDF repo (platform + SDKs) authored as a single declaration of intent. See `features/README.md`. +- **`schema/`** — Generated JSON Schemas for the canonical scenario / instance models. Regenerate via `uv run otdf-sdk-mgr schema dump` after editing the Pydantic models in `otdf-sdk-mgr/src/otdf_sdk_mgr/schema.py`. See `schema/README.md`. + +The first two are produced by the Claude Code skills under `tests/.claude/skills/` (`scenario-from-ticket`, `feature-design`, etc.) and can also be hand-authored. diff --git a/xtest/features/CLAUDE.md b/xtest/features/CLAUDE.md new file mode 100644 index 00000000..9f5e9a7e --- /dev/null +++ b/xtest/features/CLAUDE.md @@ -0,0 +1,13 @@ +# Agent guidance for xtest/features + +This directory is owned by two skills: + +- **`feature-design`** drafts new spec files here from a Jira ticket (or free-form description) using propose-then-iterate authoring. It also writes the tests-side artifacts that have to land first: the `feature_type` entry in `xtest/tdfs.py`, the scenario under `xtest/scenarios/`, and (if needed) a draft pytest. +- **`feature-orchestrate`** reads spec files and fans out per-repo subagents that implement the feature in each touched repo and open draft PRs. + +When you see a `xtest/features/.yaml` referenced: + +- It is canonical for the feature's flag name, scope, and per-repo todos. +- It is NOT canonical for status — query `gh pr list --search "head:"` per repo. + +Don't hand-author spec files in this directory unless you've also done what `feature-design` would do (add the entry to `feature_type` in `xtest/tdfs.py`, generate the scenario + draft test). Those side effects keep the spec consistent with the tests it depends on. diff --git a/xtest/features/README.md b/xtest/features/README.md new file mode 100644 index 00000000..2a1f5551 --- /dev/null +++ b/xtest/features/README.md @@ -0,0 +1,14 @@ +# xtest/features + +Specs for features that touch more than one OpenTDF repo (e.g. platform + Go SDK + Java SDK + JS SDK). + +Each `.yaml` captures: + +- The feature flag name — the `supports("")` gate string in `xtest/tdfs.py`. +- The Jira ticket driving the work, if any. +- Per-repo todo lists and the shared branch name to use across them. +- The scenario(s) under `xtest/scenarios/` that exercise the feature once each repo's PR lands. + +Specs are declarative — they describe intent, not status. PR state (open / merged / CI passing) is auto-discovered from `gh pr list --search "head:"` per repo, not stored here. + +See `CLAUDE.md` in this directory for how Claude Code skills produce and consume these files. diff --git a/xtest/schema/CLAUDE.md b/xtest/schema/CLAUDE.md new file mode 100644 index 00000000..7b215459 --- /dev/null +++ b/xtest/schema/CLAUDE.md @@ -0,0 +1,8 @@ +# Agent guidance for xtest/schema + +These JSON Schemas are the canonical reference for the on-disk YAML formats. When you need to know what fields a scenario or instance accepts: + +- **Read these files**. Don't run `python -c "from otdf_sdk_mgr.schema import ..."` to introspect — those forms aren't in the plugin's allowlist, and the JSON Schemas have the same information in declarative form (titles, types, `anyOf` for ref-vs-version pins, `additionalProperties: false`, default values, etc.). +- The files are byte-stable and sorted; safe to grep, diff, or quote. + +If a Pydantic model changes and these files drift, the user (or CI) will regenerate them via `uv run otdf-sdk-mgr schema dump`. Don't try to regenerate them yourself unless you're explicitly fixing the drift in a schema-editing PR. diff --git a/xtest/schema/README.md b/xtest/schema/README.md new file mode 100644 index 00000000..c292457a --- /dev/null +++ b/xtest/schema/README.md @@ -0,0 +1,16 @@ +# xtest/schema + +JSON Schemas for the canonical scenario / instance YAML formats. One file per Pydantic model in `otdf-sdk-mgr/src/otdf_sdk_mgr/schema.py`: + +- `scenario.schema.json` — the shape that `xtest/scenarios/.yaml` validates against. +- `instance.schema.json` — the shape of `tests/instances//instance.yaml`. + +These files are generated artifacts. To refresh them after editing a Pydantic model: + +```bash +uv run --project otdf-sdk-mgr otdf-sdk-mgr schema dump +``` + +A pytest in `otdf-sdk-mgr/tests/test_schema_sync.py` fails CI if the committed files drift from what the live models would produce. + +See `CLAUDE.md` for how Claude Code skills consume these files. diff --git a/xtest/schema/instance.schema.json b/xtest/schema/instance.schema.json new file mode 100644 index 00000000..cdf172db --- /dev/null +++ b/xtest/schema/instance.schema.json @@ -0,0 +1,261 @@ +{ + "$defs": { + "Fixtures": { + "additionalProperties": false, + "properties": { + "attributes": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Attributes" + }, + "policy": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Policy" + } + }, + "title": "Fixtures", + "type": "object" + }, + "KasPin": { + "additionalProperties": false, + "description": "Per-KAS-instance version + mode pin.", + "properties": { + "dist": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Dist" + }, + "features": { + "additionalProperties": { + "type": "boolean" + }, + "title": "Features", + "type": "object" + }, + "mode": { + "default": "standard", + "enum": [ + "standard", + "key_management" + ], + "title": "Mode", + "type": "string" + }, + "source": { + "anyOf": [ + { + "$ref": "#/$defs/SourceRef" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "title": "KasPin", + "type": "object" + }, + "Metadata": { + "additionalProperties": false, + "properties": { + "created": { + "anyOf": [ + { + "format": "date", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Created" + }, + "id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Id" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Name" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "title": "Metadata", + "type": "object" + }, + "PlatformPin": { + "additionalProperties": false, + "description": "Version pin for the platform service.\n\n`dist` references a built binary at `xtest/platform/dist//service`\nproduced by `otdf-sdk-mgr install platform:`.\n`source.ref` is a git ref to build from on demand.", + "properties": { + "dist": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Dist" + }, + "source": { + "anyOf": [ + { + "$ref": "#/$defs/SourceRef" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "title": "PlatformPin", + "type": "object" + }, + "PortsConfig": { + "additionalProperties": false, + "properties": { + "base": { + "default": 8080, + "maximum": 60000, + "minimum": 1024, + "title": "Base", + "type": "integer" + } + }, + "title": "PortsConfig", + "type": "object" + }, + "SourceRef": { + "additionalProperties": false, + "properties": { + "path": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional local checkout path", + "title": "Path" + }, + "ref": { + "description": "Git tag, branch, or SHA", + "title": "Ref", + "type": "string" + } + }, + "required": [ + "ref" + ], + "title": "SourceRef", + "type": "object" + } + }, + "additionalProperties": false, + "description": "Standalone instance definition (one platform + N KAS).\n\nPersisted to `tests/instances//instance.yaml`. Also embedded inside\nScenario to keep the \"describe a bug-repro environment\" entry point a\nsingle file.", + "properties": { + "apiVersion": { + "const": "opentdf.io/v1alpha1", + "default": "opentdf.io/v1alpha1", + "title": "Apiversion", + "type": "string" + }, + "features": { + "additionalProperties": { + "type": "boolean" + }, + "title": "Features", + "type": "object" + }, + "fixtures": { + "$ref": "#/$defs/Fixtures" + }, + "kas": { + "additionalProperties": { + "$ref": "#/$defs/KasPin" + }, + "title": "Kas", + "type": "object" + }, + "kind": { + "const": "Instance", + "default": "Instance", + "title": "Kind", + "type": "string" + }, + "metadata": { + "$ref": "#/$defs/Metadata" + }, + "platform": { + "$ref": "#/$defs/PlatformPin" + }, + "ports": { + "$ref": "#/$defs/PortsConfig" + } + }, + "required": [ + "platform" + ], + "title": "Instance", + "type": "object" +} diff --git a/xtest/schema/scenario.schema.json b/xtest/schema/scenario.schema.json new file mode 100644 index 00000000..426e11c5 --- /dev/null +++ b/xtest/schema/scenario.schema.json @@ -0,0 +1,443 @@ +{ + "$defs": { + "Fixtures": { + "additionalProperties": false, + "properties": { + "attributes": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Attributes" + }, + "policy": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Policy" + } + }, + "title": "Fixtures", + "type": "object" + }, + "Instance": { + "additionalProperties": false, + "description": "Standalone instance definition (one platform + N KAS).\n\nPersisted to `tests/instances//instance.yaml`. Also embedded inside\nScenario to keep the \"describe a bug-repro environment\" entry point a\nsingle file.", + "properties": { + "apiVersion": { + "const": "opentdf.io/v1alpha1", + "default": "opentdf.io/v1alpha1", + "title": "Apiversion", + "type": "string" + }, + "features": { + "additionalProperties": { + "type": "boolean" + }, + "title": "Features", + "type": "object" + }, + "fixtures": { + "$ref": "#/$defs/Fixtures" + }, + "kas": { + "additionalProperties": { + "$ref": "#/$defs/KasPin" + }, + "title": "Kas", + "type": "object" + }, + "kind": { + "const": "Instance", + "default": "Instance", + "title": "Kind", + "type": "string" + }, + "metadata": { + "$ref": "#/$defs/Metadata" + }, + "platform": { + "$ref": "#/$defs/PlatformPin" + }, + "ports": { + "$ref": "#/$defs/PortsConfig" + } + }, + "required": [ + "platform" + ], + "title": "Instance", + "type": "object" + }, + "KasPin": { + "additionalProperties": false, + "description": "Per-KAS-instance version + mode pin.", + "properties": { + "dist": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Dist" + }, + "features": { + "additionalProperties": { + "type": "boolean" + }, + "title": "Features", + "type": "object" + }, + "mode": { + "default": "standard", + "enum": [ + "standard", + "key_management" + ], + "title": "Mode", + "type": "string" + }, + "source": { + "anyOf": [ + { + "$ref": "#/$defs/SourceRef" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "title": "KasPin", + "type": "object" + }, + "Metadata": { + "additionalProperties": false, + "properties": { + "created": { + "anyOf": [ + { + "format": "date", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Created" + }, + "id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Id" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Name" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "title": "Metadata", + "type": "object" + }, + "PlatformPin": { + "additionalProperties": false, + "description": "Version pin for the platform service.\n\n`dist` references a built binary at `xtest/platform/dist//service`\nproduced by `otdf-sdk-mgr install platform:`.\n`source.ref` is a git ref to build from on demand.", + "properties": { + "dist": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Dist" + }, + "source": { + "anyOf": [ + { + "$ref": "#/$defs/SourceRef" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "title": "PlatformPin", + "type": "object" + }, + "PortsConfig": { + "additionalProperties": false, + "properties": { + "base": { + "default": 8080, + "maximum": 60000, + "minimum": 1024, + "title": "Base", + "type": "integer" + } + }, + "title": "PortsConfig", + "type": "object" + }, + "ScenarioSdk": { + "additionalProperties": false, + "description": "One ordered SDK selection within a scenario role.", + "properties": { + "sdk": { + "enum": [ + "go", + "java", + "js" + ], + "title": "Sdk", + "type": "string" + }, + "source": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "For Go: \"platform\" to use the monorepo module path", + "title": "Source" + }, + "version": { + "title": "Version", + "type": "string" + } + }, + "required": [ + "sdk", + "version" + ], + "title": "ScenarioSdk", + "type": "object" + }, + "ScenarioSdks": { + "additionalProperties": false, + "description": "Encrypt/decrypt split mirrors xtest's --sdks-encrypt/--sdks-decrypt.\n\nSelections are ordered to preserve the eventual argv order, and are\nde-duplicated within each role by (sdk, version, source).", + "properties": { + "decrypt": { + "items": { + "$ref": "#/$defs/ScenarioSdk" + }, + "title": "Decrypt", + "type": "array" + }, + "encrypt": { + "items": { + "$ref": "#/$defs/ScenarioSdk" + }, + "title": "Encrypt", + "type": "array" + } + }, + "title": "ScenarioSdks", + "type": "object" + }, + "SourceRef": { + "additionalProperties": false, + "properties": { + "path": { + "anyOf": [ + { + "format": "path", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional local checkout path", + "title": "Path" + }, + "ref": { + "description": "Git tag, branch, or SHA", + "title": "Ref", + "type": "string" + } + }, + "required": [ + "ref" + ], + "title": "SourceRef", + "type": "object" + }, + "Suite": { + "additionalProperties": false, + "description": "Pytest selection + flags.", + "properties": { + "containers": { + "description": "Forwarded to --containers as a whitespace-separated list", + "items": { + "enum": [ + "ztdf", + "ztdf-ecwrap" + ], + "type": "string" + }, + "title": "Containers", + "type": "array" + }, + "extra_args": { + "items": { + "type": "string" + }, + "title": "Extra Args", + "type": "array" + }, + "kexpr": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Forwarded to pytest -k", + "title": "Kexpr" + }, + "markers": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Forwarded to -m", + "title": "Markers" + }, + "targets": { + "description": "Positional pytest targets, e.g. test files or path::node ids", + "items": { + "type": "string" + }, + "title": "Targets", + "type": "array" + } + }, + "title": "Suite", + "type": "object" + } + }, + "additionalProperties": false, + "description": "Top-level scenarios.yaml model.\n\nComposes an Instance with SDK pins and a pytest Suite selection.", + "properties": { + "actual": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Actual" + }, + "apiVersion": { + "const": "opentdf.io/v1alpha1", + "default": "opentdf.io/v1alpha1", + "title": "Apiversion", + "type": "string" + }, + "expected": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Expected" + }, + "instance": { + "$ref": "#/$defs/Instance", + "description": "Inline instance definition" + }, + "kind": { + "const": "Scenario", + "default": "Scenario", + "title": "Kind", + "type": "string" + }, + "metadata": { + "$ref": "#/$defs/Metadata" + }, + "sdks": { + "$ref": "#/$defs/ScenarioSdks" + }, + "suite": { + "$ref": "#/$defs/Suite" + } + }, + "required": [ + "instance", + "suite" + ], + "title": "Scenario", + "type": "object" +}