fix(portal): show skill revisions in run details

[Gile (Gile987)]

Summary

Closes #768.

• Display each skill's pinned revision in the Run details Skills card.
• Show the first seven characters of the commit hash and the full hash on hover.
• Keep links pointed at the unversioned skill slug.
• Preserve support for legacy runs containing bare skills entries.

Demo

Before

before.mp4

After

after.mp4

Testing

• pnpm exec vitest run --config apps/portal/vite.config.ts apps/portal/src
  • 61 test files and 423 tests passed.
• pnpm --filter portal lint — passed.
• pnpm --filter portal build — passed.
• pnpm --filter portal build-storybook — passed.
• pnpm headers:check — passed.
• Manually verified version display, full-hash hover text, navigation, and legacy unversioned entries.

The repository-wide checks were also attempted:

• pnpm lint reached and passed the Portal check, then failed because several unrelated workspace packages invoke an undeclared eslint executable.
• pnpm test failed in the local Windows environment on POSIX-specific shell/path tests and root Vitest alias resolution. The scoped Portal suite above passes.

Documentation and compatibility

Updated docs/architecture/skills.md.

This change does not modify the API, database schema, dependencies, or CLI behavior.

Checklist

• CLI parity is not applicable because this is a Portal display correction.
• Added Storybook coverage.
• No database migration is required.
• No dependencies or notices were changed.

[Gile (Gile987)]

@microsoft-github-policy-service agree

[Copilot]

Copilot review overview

🟡 Changes recommended

The Storybook stories add a nested MemoryRouter, causing runtime errors; remove the local router decorator.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Remove nested MemoryRouter from Storybook decorator · New

What changed in this PR

Updates Portal run details to display pinned skill revisions while preserving legacy skill entries.

Changes:

• Adds shared skill parsing and revision fallback logic.
• Displays shortened commit hashes with full hashes on hover.
• Adds tests, Storybook coverage, and documentation.

File	Summary
docs/​architecture/​skills.md	Documents revision display behavior.
apps/​portal/​src/​pages/​RunDetail.tsx	Uses revision-aware skill links.
apps/​portal/​src/​pages/​ProfileDetail.tsx	Reuses shared parsing logic.
apps/​portal/​src/​lib/​skill-spec.ts	Parses and deduplicates skill references.
apps/​portal/​src/​lib/​skill-spec.test.ts	Tests parsing and fallback behavior.
apps/​portal/​src/​components/​SkillRevisionLinks.tsx	Renders skill links and revisions.
apps/​portal/​src/​components/​SkillRevisionLinks.test.tsx	Tests rendering and navigation.
apps/​portal/​src/​components/​SkillRevisionLinks.stories.tsx	Adds versioned and legacy stories.
apps/​portal/​src/​components/​SkillPicker.tsx	Uses shared parsing logic.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Cedric Vidal (cedricvidal)]

Thank you Gile (@Gile987) for this contribution, and welcome to Scope! 🎉 Community PRs like this one really help, and this one fixes a real problem. Run details were dropping the pinned commit and showing only the slug, so two runs of the same skill at different revisions looked the same. Moving parseSkillSpec into lib/skill-spec also removes the odd pages → components/SkillPicker import. Tests and docs are included.

Verified locally: tsc --noEmit passes, and the full portal suite passes (61 files, 423 tests).

Nothing here blocks merging. A few small follow-ups:

1. The link drops the revision. SkillRevisionLinks links to /skills/${slug}, and SkillDetail always highlights the latest revision. A run pinned to an older commit therefore links to a page that shows a different commit. We could fix this later by having SkillDetail accept something like ?revision=<hash> and linking to it here. Worth a follow-up issue rather than more work in this PR.

2. Duplicate rendering in ProfileDetail. ProfileDetail.tsx (~L347–356) renders the same slug@short-hash badge by hand with commitHash.substring(0, 7). It could use <SkillRevisionLinks> instead, which would also make profile skills clickable, or at least use shortCommitHash. SkillDetail also has two .slice(0, 7) calls that could use the helper. Optional.

3. The count changed slightly (fine, just noting it). Skills (N) now counts unique references, not unique slugs. A run with two revisions of the same skill would show both. I think that's more accurate.

LGTM 👍 Thanks again, and we'd be glad to see more contributions from you.

[Gile (Gile987)]

Nothing here blocks merging. A few small follow-ups:

1. **The link drops the revision.** `SkillRevisionLinks` links to `/skills/${slug}`, and `SkillDetail` always highlights the _latest_ revision. A run pinned to an older commit therefore links to a page that shows a different commit. We could fix this later by having `SkillDetail` accept something like `?revision=<hash>` and linking to it here. Worth a follow-up issue rather than more work in this PR.

2. **Duplicate rendering in `ProfileDetail`.** `ProfileDetail.tsx` (~L347–356) renders the same `slug@short-hash` badge by hand with `commitHash.substring(0, 7)`. It could use `<SkillRevisionLinks>` instead, which would also make profile skills clickable, or at least use `shortCommitHash`. `SkillDetail` also has two `.slice(0, 7)` calls that could use the helper. Optional.

3. **The count changed slightly (fine, just noting it).** `Skills (N)` now counts unique _references_, not unique slugs. A run with two revisions of the same skill would show both. I think that's more accurate.

LGTM 👍 Thanks again, and we'd be glad to see more contributions from you.

You're welcome. I will gladly work on a follow-up issue.

[Cedric Vidal (cedricvidal)]

Gile (@Gile987) following up on point 2 of my review: I marked it optional, but on reflection I'd really like to see it done in this PR, if you don't mind. Since this PR adds the nice shared SkillRevisionLinks component and shortCommitHash() helper, would you be willing to use them in the couple of places that still do the same thing by hand? That way it all lives in one place.

1. ProfileDetail.tsx (~L347–356) builds the same slug@short-hash badge inline. It could become <SkillRevisionLinks references={displayVersion.skillRevisions} />, which would also make profile skills clickable, like on the run details page.
2. Skill commit hashes that are shortened with an inline substring(0, 7) / slice(0, 7) could use shortCommitHash() instead:
   • SkillPicker.tsx L45 and L273
   • SkillDetail.tsx L163 and L289

There's no need to touch the other slice(0, 7) calls (CodebasePicker, VersionFooter, SkillImportWizard). They aren't about skill revisions.

If you have any questions, just ask. I'm happy to take another look as soon as you push. Thanks so much!

[Gile (Gile987)]

Gile (Gile (@Gile987)) following up on point 2 of my review: I marked it optional, but on reflection I'd really like to see it done in this PR, if you don't mind. Since this PR adds the nice shared SkillRevisionLinks component and shortCommitHash() helper, would you be willing to use them in the couple of places that still do the same thing by hand? That way it all lives in one place.

1. **`ProfileDetail.tsx` (~L347–356)** builds the same `slug@short-hash` badge inline. It could become `<SkillRevisionLinks references={displayVersion.skillRevisions} />`, which would also make profile skills clickable, like on the run details page.

2. **Skill commit hashes** that are shortened with an inline `substring(0, 7)` / `slice(0, 7)` could use `shortCommitHash()` instead:
   
   * `SkillPicker.tsx` L45 and L273
   * `SkillDetail.tsx` L163 and L289

There's no need to touch the other slice(0, 7) calls (CodebasePicker, VersionFooter, SkillImportWizard). They aren't about skill revisions.

If you have any questions, just ask. I'm happy to take another look as soon as you push. Thanks so much!

Done. ProfileDetail now uses SkillRevisionLinks, and the skill commit hashes in SkillPicker and SkillDetail use shortCommitHash(). Portal tests, typecheck, and the production build pass.