Minor version upgrading OPA/Rego compatibility and closing migration …

.github/skills/bump-version/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: bump-version
+description: 'Bump the rego-cpp version number for a new release. Use when: preparing a release, updating version strings after a tag, or when instructed to bump the version. Updates all version files across the main library and wrapper packages to keep them in sync.'
+---
+
+# Bumping the Version
+
+Update all version strings across the rego-cpp project for a new release.
+
+## When to Use
+
+- Preparing a new release (major, minor, or patch)
+- After discovering wrapper versions are out of sync with the main VERSION file
+- When instructed to bump versions
+
+## Files to Update
+
+Every release requires updating version strings in **all** of the following
+locations. Missing any one of them creates a version mismatch between the
+library and its wrapper packages.
+
+| File | Field / Pattern | Example |
+|------|----------------|---------|
+| `VERSION` | Entire file contents | `1.3.0` |
+| `wrappers/python/setup.py` | `VERSION = "X.Y.Z"` | `VERSION = "1.3.0"` |
+| `wrappers/rust/regorust/Cargo.toml` | `version = "X.Y.Z"` | `version = "1.3.0"` |
+| `wrappers/dotnet/Rego/Rego.csproj` | `<Version>X.Y.Z</Version>` | `<Version>1.3.0</Version>` |
+
+## Procedure
+
+1. Read the current version from the `VERSION` file at the repo root.
+2. Determine the new version (from user instruction or by incrementing).
+3. Update all four files listed above.
+4. Verify no other files reference the old version:
+   ```bash
+   grep -rn '"OLD_VERSION"' wrappers/ VERSION
+   ```
+5. Update the CHANGELOG with the new version header if not already present.
+
+## Common Mistakes
+
+- **Forgetting wrapper versions**: The wrapper packages (Python, Rust, .NET)
+  each have their own version string that must match the main `VERSION` file.
+  These are easy to miss because they live in different directories and formats.
+- **Cargo.lock stale**: After updating `Cargo.toml`, run `cargo update` in the
+  Rust wrapper directory if a lockfile exists, or CI may fail.

.github/skills/code-review/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: code-review
+description: 'Perform a multi-perspective code review of rego-cpp changes. Use when: reviewing a release, auditing a branch diff, evaluating a PR, or performing a pre-merge code review. Launches four parallel review subagents (Security, Performance, Usability, Conservative), verifies key findings, synthesises a unified report with severity-ranked findings, and produces actionable remediation recommendations.'
+---
+
+# Multi-Perspective Code Review
+
+Perform a structured code review by examining changes from four independent
+perspectives, cross-checking findings against source code, and producing a
+unified report with actionable recommendations.
+
+## When to Use
+
+- Before tagging a release
+- Reviewing a large branch diff or PR
+- Auditing a new subsystem (crypto, parsing, VM changes)
+- When a single-perspective review would miss cross-cutting concerns
+
+## Background
+
+A single reviewer tends toward their own bias — a security expert over-flags
+performance patterns, a performance expert under-flags input validation. This
+skill runs four parallel reviews, each with a strict lens, then synthesises
+findings where multiple perspectives converge or provide unique insight.
+
+## Perspectives
+
+| Perspective | Lens | Skill file |
+|-------------|------|------------|
+| **Security** | Defence in depth, memory safety, bounded resources, error handling, adversarial inputs, C API boundaries, fuzz coverage | [plan-security](../plan-security/SKILL.md) |
+| **Performance** | Allocation minimisation, cache-friendly access, pass count, hot-path awareness, algorithmic complexity | [plan-speed](../plan-speed/SKILL.md) |
+| **Usability** | Correctness, clarity, naming, WF precision, error message quality, one-concept-per-pass, API ergonomics | [plan-usability](../plan-usability/SKILL.md) |
+| **Conservative** | Smallest diff, backwards compatibility, API stability, reuse, no speculative generality, blast radius | [plan-conservative](../plan-conservative/SKILL.md) |
+
+## Procedure
+
+### Step 1: Identify the Diff
+
+Determine the commit range or branch diff to review.
+
+```bash
+# Example: changes since last release tag
+git diff --stat v1.2.0..HEAD
+```
+
+Group changed files by subsystem (parser, builtins, VM, C API, build system,
+wrappers) to assign review focus areas.
+
+### Step 2: Launch Four Review Subagents
+
+Spawn four Explore subagents **in parallel**, one per perspective. Each
+subagent receives:
+
+1. The same list of changed files and feature summary
+2. The perspective-specific review lens (from the table above)
+3. Specific files to examine based on the subsystem grouping
+4. Instructions to classify findings by severity and provide file/line references
+
+**Prompt template for each subagent:**
+
+> You are performing a {PERSPECTIVE}-focused code review of rego-cpp.
+> The changes add: {FEATURE_SUMMARY}.
+>
+> Your review lens: **{LENS_DESCRIPTION}**
+>
+> THOROUGHNESS: thorough
+>
+> Please examine these files and report findings:
+> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}
+>
+> For each finding, classify severity as {SEVERITY_SCALE} and provide the
+> file path and approximate line numbers. Return a structured report.
+
+Severity scales per perspective:
+- **Security**: CRITICAL / HIGH / MEDIUM / LOW / INFO
+- **Performance**: HIGH / MEDIUM / LOW impact
+- **Usability**: CONCERN / SUGGESTION / POSITIVE
+- **Conservative**: BREAKING / HIGH-RISK / MEDIUM-RISK / LOW-RISK / OK
+
+### Step 3: Verify Key Findings
+
+After collecting all four reports, identify the highest-severity findings and
+**spot-check them against source code**. Launch a verification subagent:
+
+> For each claim below, read the relevant code and report whether the claim
+> is CONFIRMED, PARTIALLY CONFIRMED, or REFUTED. Provide exact code evidence.
+> {LIST_OF_CLAIMS_TO_VERIFY}
+
+This step prevents false positives from propagating into the final report.
+Mark any unverifiable claims as such.
+
+### Step 4: Synthesise the Report
+
+Produce a unified report with these sections:
+
+#### Convergence
+Where two or more perspectives agree on the same finding. High convergence
+indicates high confidence.
+
+#### Findings by Severity
+A single table combining all verified findings, normalised to a unified
+severity scale:
+
+| Unified Severity | Mapping |
+|-----------------|---------|
+| CRITICAL / HIGH | Security CRITICAL/HIGH, Performance HIGH, Usability CONCERN (correctness bug), Conservative BREAKING |
+| MEDIUM | Security MEDIUM, Performance MEDIUM, Usability CONCERN (non-correctness), Conservative HIGH-RISK |
+| LOW | Security LOW, Performance LOW, Usability SUGGESTION, Conservative MEDIUM-RISK |
+
+Each finding gets: number, description, originating perspective(s), verification
+status, file path and line references.
+
+#### Positive Highlights
+Things the code does well, called out by any perspective. This provides
+balanced feedback and reinforces good patterns.
+
+#### Recommendations
+Ordered by priority. Split into:
+- **Before release**: correctness bugs, UB, security issues
+- **After release**: performance optimisation, tech debt, hardening
+
+#### Trade-offs
+Where perspectives conflict (e.g., security wants more validation, performance
+wants less overhead), state the conflict and the recommended resolution.
+
+### Step 5: Calibrate Against Existing Test Coverage
+
+Before finalising recommendations, check whether existing test suites
+(OPA conformance tests, regocpp.yaml, fuzzer) already cover the flagged
+scenarios. The OPA test suite is comprehensive — findings about "missing
+test coverage" must be verified against:
+
+```bash
+# List OPA test suites
+ls build/opa/v1/test/cases/testdata/v1/
+
+# Check specific suite coverage
+grep 'note:' build/opa/v1/test/cases/testdata/v1/{suite}/*.yaml
+```
+
+Drop or downgrade recommendations that duplicate existing OPA coverage.
+
+## Output Format
+
+The final report should be a structured markdown document (presented in chat,
+not saved to a file unless requested) with the sections described in Step 4.
+
+## Reference
+
+- [Example remediation plan from v1.3.0 review](./references/v1.3.0-remediation-plan.md) —
+  a concrete example of findings and the resulting fix plan.