v1.25.0

Dry run for the schema tools (v1.25.0) (#17)

* Add a dry run to the schema tools

table_*, column_*, view_* and role_* writes take dryRun: true. A call-tool
filter opens a DryRun scope (AsyncLocal) around the tool; inside it,
DataverseHttpClient records every POST/PATCH/PUT/DELETE instead of sending it
and answers with an empty 204, while GETs still go out. The result lists the
planned requests with URL, relevant headers and the exact body, plus the
tool's own output.

The production guard lets dry-run calls through, including the tools that
had their own validate-and-report dry run before (workflow_set_definition,
bpf_set_definition, solution_uninstall, whose dry run is the default). Those
keep their behaviour; the generic filter only wraps tools whose dryRun
parameter carries the generic description. The refusal message points to
dryRun.

Verified live against a sandbox: a dry-run table update sent only the GET of
the definition and recorded one PUT with the full merged body.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

* Document the dry run (v1.25.0)

README security table and comparison, modeling-patterns skill: when to use
dryRun and what a production refusal means.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

v1.24.0

macOS and Linux support for the plugin (v1.24.0) (#16)

* Build, sign and smoke-test server binaries for macOS and Linux

The release workflow builds win-x64, linux-x64, osx-arm64 and osx-x64 in a
matrix. The macOS binaries are built on a macOS runner and ad-hoc signed,
because Apple Silicon kills an unsigned binary on start. Each non-Windows
binary is started on its own platform and must answer initialize and
tools/list (.github/scripts/smoke_mcp.py).

A PR that touches the pipeline or the launchers runs the binaries job too;
the release job only runs for tags, so a PR publishes nothing.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

* Start the plugin's server on macOS and Linux

.mcp.json has no platform-specific entries, so its command is now the
extensionless ${CLAUDE_PLUGIN_ROOT}/scripts/launch: macOS/Linux execute the
shell script `launch` (-> run-server.sh), while Claude Code on Windows
resolves the same path to `launch.cmd` (-> run-server.ps1). Verified on
Windows 11, including with both files side by side.

binary-common.sh picks the release asset for its platform instead of the
fixed win-x64 one, and ensure-binary.sh no longer skips Unix. The PowerShell
SessionStart hook ends in "; exit 0" so it stays quiet where PowerShell is
missing.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

* Document macOS/Linux support (v1.24.0)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

* Smoke-test the plugin launcher on macOS and Linux

The binaries job now also starts each non-Windows binary through
scripts/launch -> run-server.sh, with the binary pre-placed in a plugin-data
directory, so the platform asset naming in binary-common.sh is exercised on
the real OS.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J4JSCheFvAEVCZLUQ29Uqj

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

v1.23.0

Safety: tool annotations, read-only mode, production guard (v1.23.0) …

v1.22.0

One-step install: plugin config, dotnet tool server, marketplace (v1.…

v1.21.2

Keep the repository in English (v1.21.2) (#11)

* Keep the repository in English

- Translate the remaining German content: CLAUDE.md, the classic-workflow
  reference and tool docs, the release setup guide, the modeling-patterns,
  solution-pipelines and classic-workflows skills, the feedback tool's
  descriptions and messages, and scattered comments and test strings.
- CLAUDE.md gains a "Language" section: commits, PRs, branches, code,
  comments, tool texts, docs and skills are English. Exceptions are German
  search keywords in skill descriptions and data that reproduces real
  content (platform labels and error texts, umlaut test data).
- LanguageTests fails the build on German text outside an allowlist that
  names each exception with its reason.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E3K7pNqV66xJbBSQQ3jkP8

* Version 1.21.2

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E3K7pNqV66xJbBSQQ3jkP8

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

v1.21.1

BPF: Befunde der zweiten Review beheben (v1.21.1) (#10)

* BPF: Befunde der zweiten Review beheben

- bpf_set_definition schreibt die Sicherung vor der Änderung; ist der
  backupFile-Pfad nicht beschreibbar, wird nichts geändert (vorher galt
  eine erfolgreiche Änderung als gescheitert).
- Mit Solution: bei der Aktivierung kommt die Instanztabelle in die
  Solution (bpf_create, bpf_set_state mit solutionUniqueName) – ohne sie
  lässt sich die Solution nicht exportieren (0x80060376).
- Prozessreihenfolge: bpf_create setzt processorder hinter die
  bestehenden Prozesse; bpf_list sortiert wie die Plattform (ohne Order
  zuletzt, Gleichstand nach Name); bpf_set_order folgt dieser Reihenfolge.
- Neue Prüfungen: Stage ohne Schritte (BPF022), Fall mit demselben Ziel
  wie else (BPF029), Stage namens "End" (BPF053), nicht änderbare Spalte
  als Datenschritt (BPF313), uniqueName ohne Publisher-Präfix (BPF009
  als Warnung), abgeschlossene Instanzen auf entfernter Stage (BPF060
  als Warnung).
- Dry-Run zeigt den Diff auch bei Fehlern; Aktivierungsfehler jeder Art
  behalten die processId; Fehlertexte präzisiert.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E3K7pNqV66xJbBSQQ3jkP8

* Version 1.21.1

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E3K7pNqV66xJbBSQQ3jkP8

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

v1.21.0

Feedback-Event Schema v2 übernehmen (#9)

dataverse_submit_feedback sendet das Event McpSessionFeedback im Schema v2:
schemaVersion, serverVersion, severity (neuer optionaler Parameter), caller,
client und clientVersion aus dem initialize-Handshake, transport; category
wird normalisiert. Die Properties baut die testbare FeedbackEvent.Build.
Server-Version 1.21.0 in Dataverse.Server.csproj, damit serverVersion stimmt.

Gleicht den Stand mit dem zweiten Repository ab, in dem die Änderung bisher
nur lag – ohne Release war sie in keiner ausgelieferten Binary.


Claude-Session: https://claude.ai/code/session_01E3K7pNqV66xJbBSQQ3jkP8

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

v1.20.0

v1.20.0

v1.19.0

v1.19.0

v1.17.0

Release-Workflow: contents:write explizit deklarieren (#2)

Der Lauf zu v1.17.0 baute Binary und NuGet-Paket fehlerfrei und scheiterte erst
im letzten Schritt: 403 "Resource not accessible by integration" beim Anlegen des
Releases. Ursache ist die Default-Workflow-Permission des Repositories, die fuer
neu angelegte Repos read-only ist - im alten Repo war sie auf write gestellt, was
im Workflow selbst nicht sichtbar war.

Die Berechtigung gehoert deshalb in den Workflow statt in eine Repo-Einstellung:
so ist sie versioniert, beim Lesen erkennbar und ueberlebt einen Umzug in ein
anderes Repository. contents:write ist gleichzeitig die kleinste ausreichende
Berechtigung - der Job braucht nichts weiter.


Claude-Session: https://claude.ai/code/session_01WMH3nm9csSVNfKDQSCesmy

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>