chore(release): bump to v0.33.0

[avrabe]

Release the typed WIT list from Array data types (#345, feature merged in #346).

Changes

• [workspace.package] version 0.32.0 → 0.33.0 (Cargo.toml + Cargo.lock)
• vscode-spar extension version 0.32.0 → 0.33.0
• Promote REQ-CODEGEN-WIT-ARRAY-001 to status: verified, release: v0.33.0

What shipped in v0.33.0

An AADL data type with Data_Representation => Array now emits a typed WIT list from spar codegen --format wit instead of the opaque list<u8>: a fixed Dimension → bounded list<T, N>, unbounded → list<T>, element resolved from Base_Type (recursively). No-Base_Type / unsized-element arrays stay opaque (no regression). Oracle-verified against wit-parser.

Metadata-only bump; the feature and its tests landed in #346 (all required checks green).

🤖 Generated with Claude Code

---

Generated by Claude Code

[github-actions]

Rivet verification gate

✅ 20/20 passed

	count
Passed	20
Failed	0
Skipped (no steps)	0

Filter: (and (= type "feature") (or (has-tag "v093") (has-tag "v0100")))

Failed artifacts

(none)

_{Updated automatically by tools/post_verification_comment.py. Source of truth: artifacts/verification.yaml.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[avrabe]

✅ v0.33.0 merged to main — STAGED for release (maintainer must cut the signed tag)

The bump is merged: main is at 4cd5948 (chore(release): bump to v0.33.0 (#347)), version is 0.33.0 (Cargo.toml + Cargo.lock + vscode-spar), and REQ-CODEGEN-WIT-ARRAY-001 is promoted to verified / release: v0.33.0. All required checks were green on both the feature PR (#346) and this bump.

This environment has no signing key (the configured commit_signing_key.pub is empty), so I cannot produce or verify a signed tag — and I won't push an unsigned one, since release.yml / branch protection expect a signed tag. The release is therefore staged for you to cut locally:

git fetch origin main
git checkout main          # should be at 4cd5948
git tag -s v0.33.0 -m "spar v0.33.0"
git tag -v v0.33.0         # confirm "Good signature"
git push origin v0.33.0    # triggers release.yml

That triggers release.yml → binaries/artifacts. If the Marketplace-publish sub-job fails, that's an expired VSCE_PAT (binaries still ship), not a release failure.

(No action needed on v0.32.0 — its tag is already present.)

---

Generated by Claude Code

[avrabe]

Follow-up: the ❌ on main's post-merge CI is a runner-side flake, not a real failure — safe to ignore for the v0.33.0 tag-cut

Posting because the post-merge CI finished (18:02) after the staged-release note above (17:58): main's run for the #347 merge (4cd5948) shows the Rivet validate (artifacts) job as ❌ FAIL (464 errors, 614 warnings, 0 broken cross-refs) — run 30031643135. This is environmental, not a content regression:

• The commit right before the bump (b39068e, feat(codegen): emit typed WIT list from Array data types (#345) #346) passed Rivet validate in CI, and chore(release): bump to v0.33.0 #347 is a metadata-only bump that passed the same check on its PR head 2b28a72 (run 30023117362 ✅) at 16:00. Identical content can't introduce 464 new errors two hours later.
• Reproduced locally with the exact CI-pinned toolchain (cargo install --locked --git .../rivet --tag v0.4.3, f25e592e): rivet validate --format text → PASS (122 warnings), exit 0, 0 broken cross-refs. The 464 "errors" do not reproduce.
• Every failing diagnostic is an unknown-field version-skew notice (e.g. field 'method' is not defined in schema for type 'feature') — INFO-level in v0.4.3 locally, counted as errors only on the runner.

Likely root cause: a stale rivet binary on self-hosted runner12. cargo install --tag v0.4.3 is a no-op when rivet-cli v0.4.3 is already present, so an older rivet build that treated unknown-field as an error can persist across jobs on that runner. Suggested fix: force a clean reinstall in the Install rivet CLI step (cargo install --force ...) or clear ~/.cargo/bin/rivet on the runners — otherwise this will keep flapping on future PRs.

Does not block the release: release.yml doesn't gate on rivet validate, so the tag-cut steps above are still good to go. No tag was cut this run — the signing key at commit_signing_key.pub is genuinely empty (no private key in this env), so signing here would be faked; leaving it to you as noted.

---

Generated by Claude Code