Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.claude/skills/update-sample-workflow/scripts/update_sample.py:
- Around line 27-33: The code uses the raw CLI value sample_id to build
sample_path which allows path traversal; before using sample_id (and similarly
the use at lines ~39-41), validate and constrain it to a safe filename (e.g.,
allow only a strict regex like /^[A-Za-z0-9._-]+$/ or explicitly strip path
separators) or use Path(sample_id).name to force a single path segment, then
construct sample_path from that sanitized value; update all places that build
paths from sample_id (sample_path and the later usage around lines 39-41) to use
the sanitized/validated identifier.

In `@src/extension/commands/load-sample-workflow.ts`:
- Around line 34-35: The handler in load-sample-workflow.ts uses blocking fs
calls (fs.readdirSync and other sync calls around samplesDir, file reads and
exists checks); replace all synchronous filesystem usage with the promise-based
API from node:fs/promises (e.g., import fsPromises or use destructured methods
like readdir, readFile, stat) and await those calls inside the same async
command function, update error handling to catch and log async errors, and
change usages of variables like files, samplesDir and any calls currently using
readdirSync/readFileSync/existsSync to their awaited fs/promises equivalents so
the extension command remains non-blocking.
- Around line 95-110: The code builds filePath by joining extensionPath and an
interpolated sampleId without sanitization, allowing path traversal; update the
logic around filePath/sampleId resolution to (1) compute a baseDir =
path.resolve(extensionPath, 'resources', 'samples'), (2) compute resolved =
path.resolve(baseDir, `${sampleId}.json`), (3) ensure
resolved.startsWith(baseDir + path.sep) (or use path.relative to verify it
doesn't escape), and if the check fails return the same LOAD_FAILED error;
additionally, restrict sampleId to a safe whitelist (e.g., alphanumeric, dashes,
underscores) before resolving to further prevent malicious names and only then
read/JSON.parse the file.

In `@src/extension/commands/open-editor.ts`:
- Around line 946-955: The LOAD_SAMPLE_WORKFLOW case currently silently returns
when message.payload?.sampleId is missing; update the handler in the switch to
validate message.payload.sampleId and, if absent, send a validation error back
to the caller instead of doing nothing—use the same response channel as
successful calls (e.g., webview.postMessage or the existing response mechanism
keyed by message.requestId) and include a clear error code/message referencing
the missing sampleId; keep the normal await
loadSampleWorkflow(context.extensionPath, webview, message.payload.sampleId,
message.requestId) path for valid payloads.

In `@src/webview/src/App.tsx`:
- Around line 351-357: The onboarding tour is currently blocked until
SAMPLE_WORKFLOW_LOADED, so if sample loading fails the tour never starts; update
the flow so first-time users still get the tour regardless of load success: when
setting pendingTourAfterSampleLoadRef.current (from payload.isFirstTimeUser) and
posting the LOAD_SAMPLE_WORKFLOW message, add a fallback that triggers the tour
even if loading fails or times out—either by handling a
SAMPLE_WORKFLOW_LOAD_FAILED message in the same onMessage handler that currently
handles SAMPLE_WORKFLOW_LOADED, or by kicking off the tour after a short timeout
if SAMPLE_WORKFLOW_LOADED hasn’t arrived; ensure you update the
SAMPLE_WORKFLOW_LOADED handling and any conditional that checks
pendingTourAfterSampleLoadRef.current to startTour() so it also starts on the
failure/timeout path.

In `@src/webview/src/components/dialogs/SampleWorkflowDialog.tsx`:
- Around line 41-43: The handler for message.type 'SAMPLE_WORKFLOW_LIST' (in
SampleWorkflowDialog.tsx) dereferences message.payload as { samples:
SampleWorkflowMeta[] } without guarding, causing a runtime crash if payload is
missing; update the handler to validate/narrow message.payload before using it
(e.g., check that message.payload is an object and that payload.samples is an
array), then call setSamples(payload.samples ?? []) only after that guard (or
fall back to an empty array) so you never dereference an undefined payload.
- Around line 131-141: The component currently treats samples.length === 0 as
"Loading..." which hides true empty results; in SampleWorkflowDialog add and use
an explicit isLoading boolean state (e.g., useState<boolean>(true)) that is set
true while fetching samples and false when the fetch completes, then change the
render branch to show "Loading..." only when isLoading is true, and render a
distinct empty-state message (e.g., "No samples available") when isLoading is
false and samples.length === 0; update the fetch logic that populates samples to
set isLoading appropriately on success/error and reference the samples array and
isLoading state in the render.

In `@src/webview/src/i18n/translations/ko.ts`:
- Line 1027: The translation key 'sample.dialog.nodeCount' uses the wrong
placeholder syntax ({{count}}) so runtime interpolation may fail; update the
value for 'sample.dialog.nodeCount' to use the same placeholder style as other
Korean translations (use {count} instead of {{count}}) so the i18n runtime can
substitute the count correctly.

In `@src/webview/src/i18n/translations/zh-TW.ts`:
- Line 994: The translation key 'sample.dialog.nodeCount' uses the wrong
interpolation token format; update its value to use the project's placeholder
syntax by replacing "{{count}} 個節點" with "{count} 個節點" so it matches other
strings and will interpolate correctly (look for the 'sample.dialog.nodeCount'
entry in the zh-TW translations).

---

Nitpick comments:
In `@src/webview/src/i18n/translations/en.ts`:
- Line 1042: The translation key sample.dialog.nodeCount uses the opposite
placeholder style ({{count}}) compared to other keys like property.optionsCount
and property.detectedVariables; update sample.dialog.nodeCount to use the
single-brace form {count} to keep placeholder formatting consistent across
translations (i18n-context.tsx already supports both formats so this is purely a
style change).