| name | gocciascript-issue-validation |
| description | Validate GocciaScript engine issues against the project-specific test262 harness. Use alongside implement-issue for GocciaScript issues that mention test262, ECMA-262/ECMA-402 conformance, Intl, or parser compatibility flags. |
GocciaScript Issue Validation
Project-specific validation rules for GocciaScript issues. Use this skill with the generic implement-issue workflow when the issue references test262, ECMAScript/ECMA-402 behavior, or compatibility flags.
Spec Lookup
For ECMA-262 or ECMA-402 semantics, use the pinned tc39-mcp@0.6.1 server from the project MCP config under .agents/mcp/ when it is available. tc39-mcp spec-reading tools default to ECMA-262, so pass the spec explicitly for the standard you are checking:
- ECMA-262 language/core built-ins:
spec: "262"
- ECMA-402 Intl behavior:
spec: "402"
- Use
spec.search when the exact clause id is unknown, for example spec.search({ spec: "402", query: "Intl.DateTimeFormat" }) for Intl work.
- Use
clause.get for the relevant clause before deciding expected behavior, for example clause.get({ spec: "402", id: "sec-intl.datetimeformat" }).
- Use
spec.crossrefs when behavior depends on abstract operations or cross-spec references. For ECMA-402 algorithms that call ECMA-262 operations, start from spec: "402" and set include_cross_spec: true.
- Use
spec.diff or spec.history with the same explicit spec when the issue may involve recent prose drift.
- Use
test262.search to map a clause id or feature area to conformance tests.
- Use
test262.get to inspect a specific conformance test when the MCP server returns one.
- Use
proposal.list or proposal.get for proposal-stage features.
Record the spec, edition, clause id, section number, and snapshot SHA when the MCP response provides one. If tc39-mcp is not available, fall back to the official TC39 sources (tc39.es/ecma262, tc39.es/ecma402) rather than guessing.
Test262 Validation
When an issue references test262 files, patterns, or categories:
- Read
docs/test262.md before running the reproduction.
- Use
scripts/run_test262_suite.ts with GocciaScriptLoaderBare; do not run stock test262 files directly through GocciaScriptLoader, GocciaTestRunner, or hand-built wrappers.
- Use the pinned test262 SHA from
.github/workflows/pr.yml or .github/workflows/ci.yml unless the issue explicitly targets another SHA.
- Build the bare loader from a clean artifact state first:
./build.pas --clean loaderbare
Use the clean form after merges, branch switches, PR syncs, generated
resource changes, or any unexplained FPC/resource compiler failure. A plain
./build.pas loaderbare is only appropriate for tight iteration after a
known-clean build.
- Run exact issue paths through the project runner, for example:
bun scripts/run_test262_suite.ts \
--suite-dir /path/to/test262-suite \
--categories intl402 \
--filter 'intl402/NumberFormat/prototype/format/example.js' \
--mode bytecode \
--jobs 1 \
--verbose
The runner supplies the compatibility flags, harness substitutions, non-strict script handling, timeout/memory limits, pinned harness behavior, and PASS/FAIL/WRAPPER_INFRA classification used by CI. Direct loader experiments are only supplemental after the project runner result is known.
