CST_AI v2.0.0

CST_AI V2.0 — Release Notes

version          = 2.0.0
release_status   = USABLE
acceptance_source= V1.18
acceptance_A     = PASSED
acceptance_B     = PASSED
acceptance_C     = PASSED

This is a release freeze, not a feature round. No product logic changed:
cst_ai_plugin/ is byte-identical to the tree that V1.18 accepted (frozen-set
aggregate hash and per-file hashes in reports/v2.0_release_freeze.json).
This round performed 0 CST contacts and 0 real solves; every number
below is carried over from a previously verified round.

---

1. What V2.0 is

CST_AI is a plugin that drives CST Studio Suite from an agent-facing tool surface
and returns structured, provenance-carrying results. The stable public layer is
five actions:

plan · run · status · inspect · resume

and the stable API version string inside the code is
PUBLIC_API_VERSION = 1.16.0, PUBLIC_API_REVISION = 1.17.0
(TOOL_SURFACE_VERSION = 1.17.0). V2.0 is the release label for this frozen,
user-accepted behaviour; the in-tree module version string
MODULE_VERSIONS["cst_ai_plugin"] = "1.15.0" was deliberately not edited,
because item 9 of the freeze round forbids touching the product implementation.

---

2. Capabilities in this release

#	Capability	What it gives the user
1	Public DSH tool surface	Five actions reachable through one launcher (cst_ai_tool_bridge.ps1), each returning a single JSON envelope; the acceptance runs drove 159 tool calls through it and 0 calls into anything else.
2	plan / run / status / inspect / resume	plan is documented and verified as zero side effect (no CST connection, no build, no solve, no project write). run executes a TaskSpec. status and inspect are offline reads of the durable store. resume continues an interrupted run.
3	Durable run store	Every run writes <store_root>/<run_id>/state.json + events.jsonl atomically (temp + fsync + os.replace), with a monotonically non-decreasing checkpoint_version. State survives tool-server and process restarts: V1.18 read status/inspect for all three acceptance runs from an independent process.
4	Solve-budget enforcement	A TaskSpec declares solve_policy (FORBID / ALLOW_ONE / ALLOW_UP_TO_N / REUSE_ONLY) and max_solves. The plan states PLANNED_SOLVE_COUNT and MAX_AUTHORIZED_SOLVES before anything runs; the platform refuses FORBID_WITH_SOLVE_STAGE. Refusals and budgets are recorded per run.
5	Build / solve / result pipeline	One TaskSpec drives CONNECT → BUILD → VERIFY → SOLVE → EXTRACT → ANALYZE → REPORT, with the stage list checked against the task kind (BUILD_ONLY, BUILD_AND_SOLVE, LOAD_EXISTING_RESULT, PARAMETER_SWEEP, COMPARE_ONLY).
6	S-parameters / Floquet / RTA	Reads the 1D S-Parameters tree, parses SZmin(i),Zmin(1) / SZmax(i),Zmin(1) channel identities into face/mode structure, and reports R_total, T_total and the residual balance A = 1 - R - T per frequency point.
7	Resonance f0 / FWHM / Q	A validated extractor: in-band minimum, baseline, half level, parabolic INTERPOLATED_F0, half-level crossings for FWHM, Q_linewidth = f0 / FWHM, with explicit validity codes. When a crossing is outside the band it reports null plus the reason instead of inventing a number.
8	Convergence observability	mesh_timeline (adaptation results, pass count, final mesh cells) and frequency_sweep_state (calculation count, final interpolation error) are read back from the solved project and reported with the rest of the observables.
9	Farfield / directivity / gain / realized gain / HPBW	Activates a stored farfield monitor with the source-locked SelectTreeItem + evaluation-list chain (it changes GUI/session state, never the model history), then reads the complex field on a theta/phi grid and reports peak directivity, gain, realized gain, beam direction and a self-computed HPBW.
10	Parameter sweep	spec.points drives one isolated project per point under one budget (ALLOW_UP_TO_N), with per-point artifacts and a unified table. Reuse is signature-checked: a mismatched signature denies reuse instead of silently reusing. Points that were already solved are never solved again.
11	Comparator capability	A semantic comparator (scalar / curve / complex / resonance / sweep comparison, overlap and semantic gate) is registered as an optional application capability. It is not reachable through the five public actions (see the capability matrix).
12	Structured ResultBundle	Every run writes result_bundle.json + result_bundle.md next to plugin_observables.json, each carrying execution_status, numerical_status, scientific_status, provenance_status, solve usage, artifacts, observables, warnings, unresolved items and errors. Large arrays are referenced by artifact path + hash, never inlined into a tool response.
13	Structured errors	Refusals and failures come back as {ok: false, error_type, stage, message, detail} with no raw traceback in the message; the four documented zero-solve error cases (unknown run_id, malformed TaskSpec, FORBID + solve stage, malformed observable identity) were verified end-to-end.

Full per-capability detail — verification stage, real-solve evidence, public-tool
availability and limitations — is in CAPABILITY_MATRIX_V2.0.md.

---

3. Acceptance summary (source: V1.18)

Acceptance	User task	Real solves	Outcome
A	"read this already solved CST project and tell me the main S-parameters, the resonance frequency, the FWHM and Q; do not recompute anything"	0	PASSED. 16 S-parameter channels × 1001 points read from the frozen V1.15 golden project; INTERPOLATED_F0 = 20.24145661869825 GHz, FWHM = 4.10544936261045 GHz, Q = 4.930387597285506, T_min = 5.033102112150721e-06; FIXTURE_RESONANCE_VALID = true.
B	"build a simple TEST dipole, compute the pattern near 20 GHz, and report directivity, gain, realized gain, main radiation direction and HPBW"	1	PASSED. Fresh TEST project; farfield monitor activated and 2664-point grid read; directivity peak 2.591272561435593 dB (1.8160477196689644), gain 2.591882899824891 dB, realized gain 2.208232664222606 dB; beam direction θ=90°, φ=55° (NEAR_DEGENERATE_AZIMUTH_RING, 35 equivalent peaks); HPBW 77.37080653476266°; sanity SANITY_CONSISTENT.
C	cross-FSS fixture family at cross_span_mm = 6.5 / 7.0 / 7.5 under ALLOW_UP_TO_N	2 new + 1 reused	PASSED. One point reused the verified golden artifact (full signature + artifact-hash validation, 0 solves), two points were solved as new isolated projects; the run was genuinely interrupted (process tree terminated, CST solver untouched) and resumed from durable state without re-solving any solved point.

Acceptance solve accounting:

A     = 0
B     = 1
C     = 2
TOTAL = 3
duplicate_solves = 0

The interruption was real, not simulated: the child runner's process tree was
terminated (taskkill /F /T, kill_returncode 0) while the solver was not
in that tree, so cst_solver_killed = false. Resume then started from the
durable points_completed on disk and reported fresh_solve_count = 1 for the
remaining point.

Final clean validation (§23 of the acceptance round) re-ran A from the public
entry point and re-validated B and C with no new solve: status + inspect +
no-op resume + artifact re-hashing for both.

---

4. Historical real-solve evidence (do not misstate this)

Each earlier round reports its own REAL_SOLVE_COUNT, and several of those are
0. A per-round zero is not a statement about the project's history. Real CST
solves have happened since V1.9 and they are recorded in hash-chained ledgers:

Ledger	Record type	Real solve runs
ledger/cst_experiment_ledger.jsonl	solve_attempt	4
ledger/v19a_control_ledger.jsonl	solver_control_run	1
ledger/v19b_floquet_ledger.jsonl	floquet_solve_run	1
ledger/v110b_convergence_ledger.jsonl	convergence_variant_solve_run	1
ledger/v110c_resonant_ledger.jsonl	resonant_fixture_solve_run	1
ledger/v110d_frequency_ledger.jsonl	frequency_sweep_variant_solve_run	1
ledger/v111_farfield_ledger.jsonl	farfield_solve_run	1
ledger/v112_sweep_ledger.jsonl	sweep_point_solve	2
ledger/v115_plugin_run_ledger.jsonl	plugin_run, solve_usage.performed == 1	1
Historical subtotal (V1.9–V1.15)		13
V1.18 acceptance	plugin_run (B = 1, C = 2)	3
Total recorded real solves to date		16

The V1.9 solves are real measurements, not simulations of one: they carry
valid_for_science: true and a full 4001-point S11 trace (e.g.
minimum_s11_db = -15.481928689032177, sampled_resonance_ghz = 0.949999988079071,
bandwidth_mhz = 98.19813508073005). The V1.11 farfield solve is real too
(ledger/v111_farfield_ledger.jsonl), which is why the angular data that V1.11A
read back was read from a really solved project — V1.11A itself added 0 solves
because it only re-activated and read back an existing result.

The detailed per-round accounting, including the V1.11A/V1.12/V1.15 corrections,
is in reports/v117_closure_addendum.md.

---

5. Known issues

Three open, non-blocking issues are recorded in KNOWN_ISSUES_V2.0.md:

• KNOWN_ISSUE_V2_0_001 — a CST_PROJECT artifact can be hashed before the
  final save/close, so the stored project-file hash can be stale. Historical
  artifacts are not changed; this is a future artifact-finalization
  improvement.
• KNOWN_ISSUE_V2_0_002 — inspect on an unknown run_id returns
  TOOL_ADAPTER_EXCEPTION and attaches a tracebac...