CONTRIBUTING.md (1)

351-351: Documentation update correctly reflects the routing change.

Swapping the unplugin-vue-router reference for Nuxt's experimental typedPages option is consistent with the dependency changes in package.json. Minor nit: typedPages is flagged as experimental in Nuxt — it may be worth a brief parenthetical note so contributors know the type-safety guarantee depends on that flag being enabled in nuxt.config.ts.

🤖 Prompt for AI Agents

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

In `@CONTRIBUTING.md` at line 351, Update the CONTRIBUTING.md note to mention that
Nuxt's typedPages option is experimental and that the type-safety guarantees for
using object-syntax named routes depend on enabling typedPages in
nuxt.config.ts; specifically, add a short parenthetical after the sentence that
recommends "object syntax with named routes" referencing the experimental nature
of the typedPages option and instructing contributors to enable typedPages in
nuxt.config.ts to get the typed route benefits.

.github/workflows/ci.yml (1)

117-118: Use $GITHUB_WORKSPACE instead of hard-coding the Actions workspace path.

Line 118 bakes in the current repository path. Using the runtime variable maintains compatibility if the repository name or checkout location changes.

Proposed change

       - name: 👑 Fix Git ownership
-        run: git config --global --add safe.directory /__w/npmx.dev/npmx.dev
+        run: git config --global --add safe.directory "$GITHUB_WORKSPACE"

🤖 Prompt for AI Agents

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

In @.github/workflows/ci.yml around lines 117 - 118, Replace the hard-coded path
in the "👑 Fix Git ownership" step by using the GitHub Actions runtime variable:
update the git config --global --add safe.directory command to use
$GITHUB_WORKSPACE instead of the literal "/__w/npmx.dev/npmx.dev" so the
safe.directory is set dynamically for the checked-out repo.

app/components/LinkedAccounts.vue (1)

4-9: Legend colours bypass the app's design tokens.

Other components in the app style via semantic tokens (bg-bg-subtle, text-fg-muted, border-border) so they respond to accent/background theme settings. The raw palette utilities here (bg-emerald-500/15, text-yellow-300, etc.) will look identical across themes and may clash on light backgrounds. Consider introducing status-specific semantic classes or at minimum verifying contrast on both light and dark themes.

🤖 Prompt for AI Agents

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

In `@app/components/LinkedAccounts.vue` around lines 4 - 9, The statusLegend array
uses raw Tailwind color utilities (statusLegend, className) which bypass the
app's semantic design tokens; replace these hardcoded palette classes with
semantic token-based classes (e.g., create status-specific utility classes like
.status-verified, .status-unverified, .status-stale, .status-failed that map to
tokens such as bg-bg-subtle / text-fg-muted / border-border or token variants
for each status) and update statusLegend.className to reference those semantic
classes so the badges respect theme/accent settings and verify contrast in both
light and dark themes.

app/composables/useKeytraceProfile.ts (1)

1-1: Rely on the project’s shared-type auto-imports here.

This composable is under app/composables, so the explicit #shared/types/keytrace import duplicates the repo’s Nuxt auto-import convention for shared/types/*.

♻️ Proposed cleanup

-import type { KeytraceAccount, KeytraceResponse } from '#shared/types/keytrace'
-

Based on learnings, “exports from shared/types/* … are auto-imported by Nuxt for composables and components. Do not add explicit import statements … in files under app/composables”.

🤖 Prompt for AI Agents

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

In `@app/composables/useKeytraceProfile.ts` at line 1, The explicit import of
KeytraceAccount and KeytraceResponse at the top of useKeytraceProfile.ts
duplicates the repo's Nuxt auto-imports for shared/types in composables; remove
the line "import type { KeytraceAccount, KeytraceResponse } from
'#shared/types/keytrace'" and rely on the project-wide auto-imported types
(references to KeytraceAccount and KeytraceResponse inside the
useKeytraceProfile composable should continue to work without the explicit
import).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

test/nuxt/a11y.spec.ts (1)

910-968: Consider expanding state coverage for the new a11y suites.

Current tests only exercise the "happy path" (populated profile, single verified GitHub account). Since ProfileHeader has distinct avatar/initials fallback branches and LinkedAccounts/AccountItem render differently per status (verified / unverified / stale / failed) and loading, adding a few more cases would catch real accessibility regressions (e.g. missing alt on the fallback avatar, colour-contrast issues on non-verified status badges, skeleton/loading ARIA).

Suggested additional cases:

• ProfileHeader: loading: true, and a profile with no avatar (initials fallback).
• LinkedAccounts: empty accounts: [], loading: true, and a mix containing unverified/stale/failed statuses.
• AccountItem: one test per non-verified status.

Not blocking for the POC, but cheap to add here so the audit actually covers the new visual states.

🤖 Prompt for AI Agents

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

In `@test/nuxt/a11y.spec.ts` around lines 910 - 968, Add a few more a11y test
cases to exercise non-happy-path states: for ProfileHeader add tests for
loading: true and for a profile without an avatar (initials fallback) using
mountSuspended(ProfileHeader) and runAxe; for LinkedAccounts add tests for
accounts: [] (empty list), loading: true, and a mixed list containing statuses
'unverified', 'stale', and 'failed'; for AccountItem add separate tests
rendering AccountItem for each non-verified status
('unverified','stale','failed') and run runAxe against each mounted component to
assert no violations. Ensure each test uses the same mountSuspended/props
pattern so the axe audit covers fallback avatar, status badges, and loading
skeleton ARIA states.

i18n/locales/de-AT.json (1)

24-43: Avoid duplicating base German strings in the Austrian variant.

These profile entries are identical to de.json, so de-AT.json can inherit them from the base locale and only override Austria-specific wording.

Proposed cleanup

-  "search": {
+  "search": {
     "instant_search": "Schnellsuche",
     "instant_search_on": "Schnellsuche aktiviert",
     "instant_search_off": "Schnellsuche deaktiviert",
     "instant_search_turn_on": "Schnellsuche aktivieren",
     "instant_search_turn_off": "Schnellsuche deaktivieren",
     "instant_search_advisory": "Die Schnellsuche sendet bei jedem Tastendruck eine Anfrage."
-  },
-  "profile": {
-    "public_interests_description": "Öffentliche Paketinteressen und Aktivitätssignale.",
-    "likes_error": "Gelikte Pakete konnten nicht geladen werden.",
-    "likes_empty": "Noch keine gelikten Pakete.",
-    "avatar_alt": "Profilavatar",
-    "unknown_profile": "Unbekanntes Profil",
-    "linked_accounts": {
-      "status": {
-        "verified": "Verifiziert",
-        "unverified": "Nicht verifiziert",
-        "stale": "Veraltet",
-        "failed": "Fehlgeschlagen"
-      },
-      "title": "Verknüpfte Konten",
-      "verified_summary": "Verifizierte Konten",
-      "legend_aria_label": "Legende zum Verifizierungsstatus von Konten",
-      "empty": "Keine verknüpften Konten"
-    }
   }

Based on learnings, “when using country locale variants (e.g., es-419, es-ES), place only translations that differ from the base language in variant JSON files.”

🤖 Prompt for AI Agents

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

In `@i18n/locales/de-AT.json` around lines 24 - 43, The de-AT locale duplicates
the entire "profile" block from the base German locale; remove the redundant
keys under "profile" in de-AT.json and leave only Austria-specific overrides (if
none, remove the "profile" object entirely) so the app falls back to de.json for
shared strings; target the "profile" object and its nested keys like
"public_interests_description", "likes_error", "likes_empty", "avatar_alt",
"unknown_profile", and the "linked_accounts" block when pruning duplicates.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/pages/profile/[identity]/index.vue (1)

242-249: ⚠️ Potential issue | 🟡 Minor

Keytrace section still renders for non-domain identities.

useKeytraceProfile(identity) is invoked unconditionally, and the mock/real endpoint returns a synthesised profile for any handle. Non-domain identities (e.g. atproto handles) will still display a "Linked Accounts" block. Please gate the <section> on a domain-like check (or on a real Keytrace signal once wired), as already noted in the previous review round.

🤖 Prompt for AI Agents

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

In `@app/pages/profile/`[identity]/index.vue around lines 242 - 249, The Keytrace
block (ProfileHeader + LinkedAccounts) is rendered unconditionally because
useKeytraceProfile(identity) returns fake profiles for non-domain handles; wrap
that <section> in a domain-check so it only renders for domain-like identities.
Add a small computed or helper (e.g., isDomainIdentity(identity) or computed
property isDomain) that checks identity format (e.g., contains a dot and not an
at-prefix, or use a regex like /^[^@]+\.[^@]+$/) and replace the unconditional
section with <section v-if="isDomain">…</section> (keeping existing props
keytraceProfile, keytraceLoading, keytraceAccounts and the useKeytraceProfile
call intact). Ensure the symbol names referenced are isDomain (or
isDomainIdentity), useKeytraceProfile, ProfileHeader, and LinkedAccounts so
reviewers can locate the change.

app/components/AccountItem.vue (2)

218-230: formatDate is locale-locked to en-US.

Even once strings are translated, dates will render in en-US form for every user. Read the active locale from useI18n() (or pass it in) so the formatter follows the user's language.

♻️ Proposed fix

-function formatDate(value: string): string {
+const { locale } = useI18n()
+
+function formatDate(value: string): string {
   const date = new Date(value)
   if (Number.isNaN(date.getTime())) {
-    return 'Unknown date'
+    return $t('profile.linked_accounts.unknown_date')
   }
 
-  return new Intl.DateTimeFormat('en-US', {
+  return new Intl.DateTimeFormat(locale.value, {
     month: 'short',
     day: 'numeric',
     year: 'numeric',
     timeZone: 'UTC',
   }).format(date)
 }

🤖 Prompt for AI Agents

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

In `@app/components/AccountItem.vue` around lines 218 - 230, The formatDate
function is hardcoded to 'en-US'; update it to use the runtime locale from
useI18n() (or accept a locale parameter) so dates render per user language:
inside formatDate (or its caller) obtain the active locale from
useI18n().locale.value and pass that to new Intl.DateTimeFormat instead of
'en-US', keep the same options (month/day/year/timeZone) and preserve the NaN
check and 'Unknown date' return; reference function name formatDate and the i18n
hook useI18n to locate where to change the code.

---

14-44: User-visible copy and labels should go through i18n.

The project uses nuxtjs/i18n (and this PR is updating locale files per the AI summary), but this component hard-codes every user-visible string: platformLabelMap, proofMethodLabelMap, statusLabelMap, verificationSteps, "Unknown date", "Re-verification failed: …", "Checking...", "Re-verify", "Re-verify Claim", "via {method}", "Added", "Last checked". Non-English locales will see English-only output, and translations will require a second pass over the component.

Please route all displayed strings through $t() / useI18n and move the copy into the locale schema alongside the keys the sibling components already register.

Also applies to: 75-80, 187-191, 218-230, 307-318

🤖 Prompt for AI Agents

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

In `@app/components/AccountItem.vue` around lines 14 - 44, This component
hardcodes all user-visible copy (see platformLabelMap, platformIconMap,
proofMethodLabelMap, statusLabelMap, verificationSteps and literal strings like
"Unknown date", "Re-verification failed: …", "Checking...", "Re-verify",
"Re-verify Claim", "via {method}", "Added", "Last checked"); update the
component to use nuxt-i18n (useI18n or this.$t) for every displayed label and
message, replace the map values and hard-coded strings with translation keys
(e.g. account.platform.github, account.proofMethod.pgp, account.status.verified,
account.actions.reverify, account.messages.unknownDate, etc.), and add those
keys to the locale schema/JSON used by sibling components so translations exist
for all locales; keep platformIconMap as-is (icons are not user copy) but ensure
any user-facing text derived from those maps uses translated labels.

server/api/keytrace/[domain].ts (1)

194-195: Stale comment — no "mock mode" branch exists in this handler.

The comment references a mock-mode toggle that is not implemented. Either drop the reference or wire the toggle back in so the code matches the intent.

♻️ Proposed cleanup

-  // If Keytrace is unavailable and mock mode isn't allowed, return a neutral profile.
+  // Keytrace fetch failed — return a neutral "service unavailable" profile.
   return buildServiceUnavailableProfile(domain)

🤖 Prompt for AI Agents

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

In `@server/api/keytrace/`[domain].ts around lines 194 - 195, The inline comment
above the return to buildServiceUnavailableProfile(domain) references a
non-existent "mock mode"; remove or correct that stale comment or, if mock
behavior is intended, implement a real toggle and branch: either delete the
"mock mode" phrase so the comment simply states the handler returns a neutral
profile when Keytrace is unavailable, or add a boolean toggle (e.g.,
KEYTRACE_MOCK_ALLOWED or isKeytraceMockEnabled) and a conditional in the handler
that returns a mock profile when enabled otherwise calls
buildServiceUnavailableProfile(domain); update any tests accordingly.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

server/api/keytrace/reverify.post.ts (1)

9-15: Unnecessary one-line wrappers.

mapReverifyStatus just forwards to mapKeytraceVerificationStatus, and getReverifyLastCheckedAt is a one-line expression used only once. Inlining both would remove indirection without hurting readability.

♻️ Proposed refactor

-function mapReverifyStatus(claim: ClaimVerificationResult): KeytraceReverifyResponse['status'] {
-  return mapKeytraceVerificationStatus(claim)
-}
-
-function getReverifyLastCheckedAt(claim: ClaimVerificationResult): string {
-  return getOptionalClaimField(claim, 'lastVerifiedAt') || claim.claim.createdAt
-}
-
 function matchesAccount(
@@
     const response: KeytraceReverifyResponse = {
-      status: mapReverifyStatus(matchedClaim),
-      lastCheckedAt: getReverifyLastCheckedAt(matchedClaim),
+      status: mapKeytraceVerificationStatus(matchedClaim),
+      lastCheckedAt:
+        getOptionalClaimField(matchedClaim, 'lastVerifiedAt') || matchedClaim.claim.createdAt,
       failureReason: matchedClaim.error || undefined,
     }

🤖 Prompt for AI Agents

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

In `@server/api/keytrace/reverify.post.ts` around lines 9 - 15, Remove the
unnecessary one-line wrapper functions: replace calls to
mapReverifyStatus(claim) with mapKeytraceVerificationStatus(claim) and replace
calls to getReverifyLastCheckedAt(claim) with the expression
getOptionalClaimField(claim, 'lastVerifiedAt') || claim.claim.createdAt; then
delete the mapReverifyStatus and getReverifyLastCheckedAt function declarations
to eliminate indirection and keep only the original helper functions
mapKeytraceVerificationStatus and getOptionalClaimField.

server/api/keytrace/[domain].ts (2)

130-131: Stale comment referencing removed mock mode.

The inline comment mentions "mock mode isn't allowed", but per the PR description the misleading mock profile fallback was explicitly removed. Consider rewording to reflect current behaviour.

✏️ Proposed fix

-  // If Keytrace is unavailable and mock mode isn't allowed, return a neutral profile.
+  // Keytrace is unavailable — return a neutral service-unavailable profile.
   return buildServiceUnavailableProfile(domain)

🤖 Prompt for AI Agents

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

In `@server/api/keytrace/`[domain].ts around lines 130 - 131, The inline comment
above the return of buildServiceUnavailableProfile(domain) is stale—remove the
"mock mode isn't allowed" wording and rephrase to reflect current behavior:
state simply that when Keytrace is unavailable the service returns a
neutral/unavailable profile. Update the comment text near
buildServiceUnavailableProfile(domain) to something like "If Keytrace is
unavailable, return a neutral service-unavailable profile" so it no longer
references removed mock mode.

---

52-69: Add explicit fallback for addedAt to ensure non-null value.

addedAt is assigned directly from claim.claim.createdAt without a fallback. Whilst TypeScript compilation passes with strict mode enabled, adding a defensive fallback (e.g., claim.claim.createdAt ?? new Date(0).toISOString()) would protect against runtime scenarios where the external package's actual data differs from its type definitions. The lastCheckedAt field already has a sensible fallback chain, but addedAt should follow the same pattern for consistency.

🤖 Prompt for AI Agents

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

In `@server/api/keytrace/`[domain].ts around lines 52 - 69, The
mapClaimsToAccounts function assigns addedAt directly from claim.claim.createdAt
without a defensive fallback; update the addedAt assignment in
mapClaimsToAccounts to use a fallback (e.g., claim.claim.createdAt ?? new
Date(0).toISOString()) so addedAt is never null/undefined at runtime and matches
the string type expected by KeytraceResponse['accounts'].

app/components/AccountItem.vue (1)

244-282: Duplicated avatar/name markup across the v-if/v-else branches.

The only difference between the LinkBase (when account.url exists) and the plain div branches is the wrapping element. The avatar container, <img>/icon fallback, and display-name <p> are copy-pasted identically. Extracting a <component :is="..."> or an inner template block would remove ~18 lines of duplication and prevent future drift.

♻️ Proposed refactor

-          <LinkBase
-            v-if="account.url"
-            :to="account.url"
-            noUnderline
-            class="inline-flex items-center gap-3 min-w-0 hover:text-accent"
-          >
-            <div
-              class="size-10 rounded-full border border-border overflow-hidden bg-bg-muted shrink-0 flex items-center justify-center"
-            >
-              <img
-                v-if="accountAvatar"
-                :src="accountAvatar"
-                :alt="accountDisplayName"
-                class="w-full h-full object-cover"
-              />
-              <span v-else :class="platformIconClass" class="size-4" aria-hidden="true" />
-            </div>
-            <p class="font-mono text-base sm:text-lg font-medium min-w-0 break-words">
-              {{ accountDisplayName }}
-            </p>
-          </LinkBase>
-
-          <div v-else class="inline-flex items-center gap-3 min-w-0">
-            <div
-              class="size-10 rounded-full border border-border overflow-hidden bg-bg-muted shrink-0 flex items-center justify-center"
-            >
-              <img
-                v-if="accountAvatar"
-                :src="accountAvatar"
-                :alt="accountDisplayName"
-                class="w-full h-full object-cover"
-              />
-              <span v-else :class="platformIconClass" class="size-4" aria-hidden="true" />
-            </div>
-            <p class="font-mono text-base sm:text-lg font-medium min-w-0 break-words">
-              {{ accountDisplayName }}
-            </p>
-          </div>
+          <component
+            :is="account.url ? 'LinkBase' : 'div'"
+            v-bind="account.url ? { to: account.url, noUnderline: true } : {}"
+            class="inline-flex items-center gap-3 min-w-0"
+            :class="account.url ? 'hover:text-accent' : ''"
+          >
+            <div
+              class="size-10 rounded-full border border-border overflow-hidden bg-bg-muted shrink-0 flex items-center justify-center"
+            >
+              <img
+                v-if="accountAvatar"
+                :src="accountAvatar"
+                :alt="accountDisplayName"
+                class="w-full h-full object-cover"
+              />
+              <span v-else :class="platformIconClass" class="size-4" aria-hidden="true" />
+            </div>
+            <p class="font-mono text-base sm:text-lg font-medium min-w-0 break-words">
+              {{ accountDisplayName }}
+            </p>
+          </component>

🤖 Prompt for AI Agents

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

In `@app/components/AccountItem.vue` around lines 244 - 282, The avatar + name
block is duplicated between the LinkBase (when account.url) and the plain div
branch; extract that repeated markup into a single reusable wrapper and render
it with a dynamic root instead of duplicating it. Replace the two branches with
one element that chooses its tag/component via :is (or a small functional
subcomponent) using the same props and bindings (preserve accountAvatar,
accountDisplayName, platformIconClass, and the noUnderline/class props when
using LinkBase) so the inner structure (avatar container, <img> fallback, and
<p> display-name) exists only once and is shared for both the LinkBase and
non-link cases.

server/utils/keytrace.ts (1)

6-42: Derive the reverse map from the forward map to prevent drift.

platformToClaimTypeMap and claimTypeToPlatformMap are maintained as two separate literals with overlapping data. Any platform added to one but not the other will silently cause round-trip mismatches (e.g. a reverify request and a [domain] response disagreeing on the platform label). Deriving the reverse map once guarantees consistency.

♻️ Proposed refactor

 const platformToClaimTypeMap: Record<string, string> = {
   github: 'github',
   dns: 'dns',
   mastodon: 'activitypub',
   bluesky: 'bsky',
   npm: 'npm',
   tangled: 'tangled',
   pgp: 'pgp',
   twitter: 'twitter',
   linkedin: 'linkedin',
   instagram: 'instagram',
   reddit: 'reddit',
   hackernews: 'hackernews',
   orcid: 'orcid',
   itchio: 'itchio',
   discord: 'discord',
   steam: 'steam',
 }

-const claimTypeToPlatformMap: Record<string, string> = {
-  github: 'github',
-  dns: 'dns',
-  activitypub: 'mastodon',
-  bsky: 'bluesky',
-  npm: 'npm',
-  tangled: 'tangled',
-  pgp: 'pgp',
-  twitter: 'twitter',
-  linkedin: 'linkedin',
-  instagram: 'instagram',
-  reddit: 'reddit',
-  hackernews: 'hackernews',
-  orcid: 'orcid',
-  itchio: 'itchio',
-  discord: 'discord',
-  steam: 'steam',
-}
+const claimTypeToPlatformMap: Record<string, string> = Object.fromEntries(
+  Object.entries(platformToClaimTypeMap).map(([platform, claimType]) => [claimType, platform]),
+)

🤖 Prompt for AI Agents

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

In `@server/utils/keytrace.ts` around lines 6 - 42, platformToClaimTypeMap and
claimTypeToPlatformMap are duplicated and can drift; replace the hand-maintained
reverse literal by deriving claimTypeToPlatformMap from platformToClaimTypeMap
(e.g. invert the entries) so every platform->claimType mapping automatically
produces the claimType->platform mapping. Update the declaration for
claimTypeToPlatformMap to be created from Object.entries/platformToClaimTypeMap
(or equivalent) and keep the same Record<string,string> typing, ensuring any
duplicate keys are handled or asserted if needed.

app/pages/profile/[identity]/index.vue (1)

241-248: Keytrace section renders for every identity, relying on server-side empty fallback.

This section is still unconditional — for non-domain handles (e.g. atproto handles routed through /profile/[identity]) the /api/keytrace/[domain] endpoint will return buildFallbackProfile, so the user sees a ProfileHeader populated with a Dicebear avatar and a “No Keytrace claims found for …” description plus an empty LinkedAccounts panel. That is arguably better than the previous fabricated-accounts behaviour, but it still surfaces a Keytrace-branded block on handles that shouldn’t have one. Consider gating the whole section behind a simple domain-shape check or keytraceAccounts.length > 0 once loading completes.

🤖 Prompt for AI Agents

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

In `@app/pages/profile/`[identity]/index.vue around lines 241 - 248, The Keytrace
UI is rendered unconditionally; change the template to only render the section
when the identity looks like a domain or when keytrace data is present after
loading—e.g., wrap the <section> containing ProfileHeader and LinkedAccounts in
a v-if that checks a domain-shape test on prop identity (simple regex) OR
(keytraceLoading === false && keytraceAccounts && keytraceAccounts.length > 0).
Update references to ProfileHeader, LinkedAccounts, keytraceAccounts,
keytraceLoading and identity so the block is gated and fallback
buildFallbackProfile results won’t surface Keytrace UI for non-domain handles.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes