[AAASM-2105] 🔧 (npm): Bump root + 4 runtime sub-packages to 0.0.1-alpha.2

[Chisanan232]

Description

Bump node-sdk from 0.0.1-alpha.1 → 0.0.1-alpha.2 for the cross-repo alpha-2 pre-release dry-run.

Diff

5 single-line version-field edits in package.json files:

• package.json (root)
• packages/runtime-darwin-arm64/package.json
• packages/runtime-darwin-x64/package.json
• packages/runtime-linux-arm64/package.json
• packages/runtime-linux-x64/package.json

pnpm-lock.yaml unchanged — this is the AAASM-2098 fix paying off. The workspace:* protocol in optionalDependencies resolves to local workspace links (version: link:packages/runtime-*) which store no version, so workspace bumps don't drift the lockfile.

Compared to the alpha-1 bump (AAASM-1934), this PR is 6 lines smaller and zero lockfile churn.

Related Issues

• Jira ticket: AAASM-2105
• Parent Story: AAASM-1234 — F118: Release-trigger
• Epic: AAASM-1199

Testing

• pnpm install --frozen-lockfile — exit 0
• pnpm test --run — 179 passed, 0 failed, 2 skipped
• grep -rnE '"version": "0\.0\.1-alpha\.1"' package.json packages/ — 0 hits

— Claude Code (Opus 4.7, 1M context)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Chisanan232]

Claude Code review — AAASM-2105

CI state

24/25 SUCCESS — mergeable=MERGEABLE, mergeStateStatus=UNSTABLE. One failure: napi-build (windows-latest, 22). Classification:

The Windows failure is a runner-environmental timing flake

FAIL tests/native-napi-integration.test.ts > native napi integration > handles 10k sendEvent calls without meaningful event-loop lag
AssertionError: expected 358.8735 to be less than 250
expect(maxLag).toBeLessThan(250);

The test asserts that the maximum event-loop lag across a 10k-sendEvent burst is under 250ms. The observed 358.87ms on Windows is 43% over the threshold. The same test passes on ubuntu + macos at Node 22, 20, and 18 (12/12 unix-runner combinations green). This is a classic GitHub Actions Windows-runner timing-noise pattern — the runner's scheduler granularity and process priority management can spike the event-loop lag well past sub-second thresholds even on a workload that runs in <2 seconds.

The threshold of 250ms is fragile on Windows. The right long-term fix is one of:

• Add a retry decorator (it.retry(3)) to the timing assertion
• Loosen the Windows-specific threshold (maxLag < 600 on win32)
• Skip the test on Windows entirely (the unix matrix already covers the assertion)

Out of scope for this PR — it's a pure version bump. The flaky-test fix deserves its own follow-up ticket if the rerun doesn't clear it.

I've initiated a job rerun via gh run rerun --job 78223132307. If it stays red on the retry, this is per the user's pre-authorized "ignore acceptance/runner flakes" classification.

Scope vs. acceptance criteria

AC	Verified	Status
package.json root version → "0.0.1-alpha.2"	Yes	✅
4 × packages/runtime-*/package.json version → "0.0.1-alpha.2"	Yes	✅
pnpm-lock.yaml regenerated	No diff — and this is correct: AAASM-2098's workspace:* protocol resolves to link:packages/runtime-* which stores no explicit version. Workspace bumps don't drift the lockfile. This is the AAASM-2098 fix paying off.	✅
pnpm install --frozen-lockfile clean	Yes — exit 0	✅
pnpm test --run clean	179 passed, 0 failed, 2 skipped (locally; the Windows CI flake is the only deviation)	✅ (one platform-specific flake noted)

Compared to the alpha-1 bump (AAASM-1934)

Metric	Alpha-1 (AAASM-1934)	Alpha-2 (this PR)
Files touched	7 (5 package.json + pnpm-lock.yaml + a separate lockfile sync PR)	5 (5 package.json)
pnpm-lock.yaml changes	~26 lines + a follow-up sync PR	0 lines
Cross-PR coordination	required (AAASM-1934 + AAASM-2098 sync)	none

The AAASM-2098 fix shrinks every future workspace bump by 6+ lines and eliminates the lockfile-drift class of bug. This PR is the first demonstration of that win.

Verdict

Ready for human approval and merge — pending Windows job rerun. The single failure is a documented platform-specific timing-flake category that the user pre-authorized to ignore. The scope-AC items are all satisfied; the lockfile-stable property from AAASM-2098 works exactly as intended.

— Claude Code (Opus 4.7, 1M context)