✨ feat: enhance medialib image handling and add asset URL resolution

- Implemented `resolveApiAssetUrl` function to normalize asset URLs based on API base.
- Updated `MedialibImage` component to utilize new asset URL resolution and added support for alt text and class properties.
- Enhanced image loading behavior with improved width measurement and focal point handling.
- Added placeholder image handling and improved accessibility with alt text.
- Introduced new test script for auditing broken links in skill documentation.
- Expanded seeded test content to include medialib entries and updated related tests for pagebuilder previews.
- Improved global setup and teardown logging for clarity on seeded content management.

api/collections/content.yml

@@ -3,6 +3,7 @@
 ########################################################################
 
 name: content
+uploadPath: ../media/content
 meta:
   label: { de: "Inhalte", en: "Content" }
   muiIcon: article

api/collections/medialib.yml

@@ -3,6 +3,7 @@
 ########################################################################
 
 name: medialib
+uploadPath: ../media/medialib
 meta:
   label: { de: "Mediathek", en: "Media Library" }
   muiIcon: image_multiple
@@ -50,6 +51,12 @@ permissions:
       post: true
       put: true
       delete: true
+  "token:${ADMIN_TOKEN}":
+    methods:
+      get: true
+      post: true
+      put: true
+      delete: true
 
 imageFilter:
   xs-webp:

api/hooks/AGENTS.md

@@ -2,6 +2,14 @@
 
 Hook files run inside the tibi-server Go runtime (goja).
 
+For the full workflow, prefer the `tibi-hook-authoring` skill.
+
+## Related skills
+
+- `security-hardening-and-token-strategy` when hooks touch secrets, external requests, auth, or risky capabilities.
+- `tibi-actions-and-forms` when the behavior is endpoint-like and should be modeled as an action instead of collection CRUD.
+- `troubleshooting-and-debugging` when goja/runtime failures span config, auth, hook execution, or reverse-proxy behavior.
+
 ## Conventions
 
 - Wrap hook files in an IIFE: `;(function () { ... })()`.
@@ -9,6 +17,7 @@ Hook files run inside the tibi-server Go runtime (goja).
 - Use inline type casting with `/** @type {TypeName} */ (value)` and typed collection entries from `types/global.d.ts`.
 - Avoid `@ts-ignore`; use proper casting instead.
 - Use `const` and `let` instead of `var`. The tibi-server runtime supports modern JS declarations.
+- Public-read or mutation hooks that affect rendered content must be reviewed together with `filter_public.js`, `config.js`, and cache invalidation behavior.
 
 ## context.filter — Go object quirk
 
@@ -45,3 +54,4 @@ instead, only add authorization filters (e.g. `{ userId: userId }`).
 - When creating or modifying collections/hooks: extend or create corresponding API tests in `tests/api/`.
 - After hook changes, run only affected API tests: `npx playwright test tests/api/filename.spec.ts`.
 - When tests fail, clarify whether the hook or the test needs adjustment — coordinate with the user.
+- If hook changes affect public rendering, add or rerun the narrowest SSR/public-read validation instead of relying only on CRUD-oriented API tests.

api/hooks/ssr/AGENTS.md

@@ -2,6 +2,14 @@
 
 Server-side rendering via goja (Go JS runtime) with HTML caching.
 
+For the full workflow, prefer the `tibi-ssr-caching` skill.
+
+## Related skills
+
+- `frontend-architecture` when SSR changes interact with route loading, i18n, or `App.svelte` data flow.
+- `media-seo-publishing` when SSR output includes image URLs, SEO metadata, or publication timing.
+- `tibi-hook-authoring` when SSR changes depend on neighboring hook behavior such as public filtering or cache invalidation.
+
 ## Request flow
 
 1. `get_read.js` receives the request and calls `lib/ssr-server.js`.
@@ -11,6 +19,8 @@ Server-side rendering via goja (Go JS runtime) with HTML caching.
 5. During SSR, `App.svelte` calls the same `loadContent(...)` path directly inside `typeof window === "undefined"`.
 6. Rendered HTML is stored in the `ssr` collection together with dependency tracking strings.
 
+Keep browser and SSR content loading on the same application path whenever possible. Do not fork a second data-loading model for SSR unless the current architecture explicitly requires it.
+
 ## Build
 
 - SSR bundle is built via `yarn build:server` and outputs to `lib/app.server.js`.
@@ -29,6 +39,7 @@ Server-side rendering via goja (Go JS runtime) with HTML caching.
 - SSR route validation is active in `config.js`.
 - Public page URLs are language-prefixed (`/de/...`, `/en/...`), while `content.path` in the DB is stored without that prefix.
 - `ssrValidatePath()` must strip the language prefix before querying content and return a canonical language-prefixed URL when needed.
+- If route validation changes, inspect `api/hooks/config.js`, `filter_public.js`, and the frontend route-loading path together instead of patching only one side.
 
 ## 404 signaling
 
@@ -37,3 +48,8 @@ The SSR hook (`get_read.js`) checks `context.is404` after rendering to determine
 `NotFound.svelte` sets `context.is404 = true` during SSR. When the component renders (only when the page is not found), its top-level script sets the flag. The goja runtime provides `context` as a global during SSR, so it's available from the compiled frontend code.
 
 When adding a 404 page or changing the not-found logic, ensure `context.is404` is still set during SSR.
+
+## Related validation
+
+- After SSR changes, run `yarn build:server` plus the narrowest reachable SSR/public-read check.
+- If caching or publication behavior changed, also rerun the relevant mutation-side invalidation check instead of relying on HTML diffing alone.