fix(action): reject outside projRoot links in docs

[wu21-web]

Description

a doc link containing ../ made the check look at files outside the project folder on the CI machine

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• make test passes locally
• Manual testing (describe below)

Checklist

• My code follows the project's coding style (go fmt, go vet)
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or my feature works
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly (if applicable)
• I have signed the CLA
• I did not use AI/LLM to create this PR, or I disclosed the tool/model below and reviewed its output; I did not attribute commits to AI and will answer maintainer questions and review comments myself without AI/LLM.
  Thank you to @sourcery-ai for discovering this issue in the action contract.

Related Issues

n/a

[github-actions]

🔍 OpenCodeReview found 1 issue(s) in this PR.

• ✅ Successfully posted inline: 1 comment(s)

[github-actions]

Consider also applying the repoAbsPath guard to listEntries (line 676) for defense-in-depth. While current callers pass constants (SKILL_ROOTS), future callers might pass user-derived paths. Applying the same traversal check consistently across all functions that join repoRoot with an external path would make the codebase more robust against future regressions.

[chaojixinren]

The fix looks correct for the issue described in this PR. repoAbsPath() prevents ..-based paths from escaping repoRoot, and the new regression tests cover both the helper itself and the end-to-end link-check behavior.

I also considered whether an in-repo symlink pointing outside the repository could bypass this check, since fs.statSync() follows symlinks. In theory that is possible. However, the current repository does not contain any symlinks, and exploiting that case would require a deliberately added symlink plus a matching documentation link and an existing target outside the checkout. I don't think that edge case should block this fix; it can be treated as future defense-in-depth if the repository starts relying on symlinked paths.

Overall, this addresses the reported path traversal/false-positive issue cleanly. Thanks for the fix and for adding the regression coverage.