Check SCSpecType is a superset of SCValType

[leighmcculloch]

What

Add a CI check that every SCValType variant has a matching SC_SPEC_TYPE_ counterpart, excluding the three internal values that cannot cross a contract function boundary.

Why

Nothing catches a new SCValType landing without a corresponding SCSpecType, which leaves a value type that contracts can pass but cannot declare in their spec — the check fails today on SCV_EXECUTABLE_TAG.

[Copilot]

Pull request overview

Adds CI validation intended to ensure contract-visible SCValType variants have matching SCSpecType variants.

Changes:

• Adds an XDR type-comparison script.
• Runs the check through GitHub Actions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.scripts/check-scspectype-superset.ts	Implements the superset check.
.github/workflows/scspectype-superset.yml	Adds CI execution for the check.

Suppressed comments (1)

.scripts/check-scspectype-superset.ts:20

• This check is guaranteed to fail on the current tree: SCV_EXECUTABLE_TAG is present in SCValType, is not excluded here, and SC_SPEC_TYPE_EXECUTABLE_TAG does not exist. Because the new workflow runs this on every push and pull request, it introduces permanently failing CI. Add the corresponding spec type (and required XDR handling/generated updates), or exclude it here only if it truly cannot cross a contract boundary, before enabling the workflow.

const missing = [...new Set(val.map((name) => name.slice("SCV_".length)))]
  .filter((name) => !EXCLUDED.includes(name))
  .filter((name) => !new RegExp(`\\bSC_SPEC_TYPE_${name}\\b`).test(spec));

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.