@se-studio/skills 1.1.0 → 1.1.3

package/CHANGELOG.md

@@ -1,5 +1,55 @@
 # @se-studio/skills
 
+## 1.1.3
+
+### Patch Changes
+
+- Bulk version bump: patch for all packages
+
+## 1.1.2
+
+### Patch Changes
+
+- Exclude redirect sources from sitemaps + robust protection against self and circular redirects.
+
+  - `buildRedirectMap` now normalizes internal paths (leading + trailing `/` to match urlCalculators + sitemap conventions) and reliably drops self-redirects (A → A). It also detects longer redirect cycles (A → B → A, etc.), drops the participating `from` rules from the baked map, and emits a `console.warn` during construction (visible in build/generate scripts).
+  - New exported utility: `filterSitemapEntriesExcludingRedirects(entries, redirectMap)`. Works on any `{ url: string }[]` (SitemapEntry, ISitemapEntry, etc.).
+  - The standard marketing site sitemap helper now accepts an optional `redirectMap` in `getSitemapEntries({ includeUnindexed, redirectMap })`. When provided, any URL that is the source of an active redirect is excluded from the generated sitemap entries. This is the recommended way to keep sitemaps clean when using editor-managed redirects.
+  - Widened the public `getSitemapEntries` option type in app helpers (additive; existing callers unaffected).
+  - Updated example app sitemaps (main + unindexed) to demonstrate fetching the map and passing it.
+  - Skill docs (`se-marketing-sites-redirects`) now include a "Redirects and sitemaps" section with usage patterns + notes on the improved cycle/self protection. Also updated routing docs.
+  - `buildRedirectMap` / `RedirectMap` / `getRedirectMap` behaviour for the middleware baked map is now safer (no self-loops or cycles will be baked).
+
+  Consumers using the `marketingSiteSitemap` helper + `getRedirectMap` at build time can now easily exclude redirect sources from both their static redirect map (for middleware) and their sitemaps in one consistent way.
+
+  See the redirect skill for the full recommended build-time pattern and the new filter helper.
+
+## 1.1.1
+
+### Patch Changes
+
+- Simplify Redirect content model + add tagType as a first-class internal link target.
+
+  The original redirect content type (added in the previous minor) used a verbose Contentful model with separate `fromPage`/`fromArticle`/etc. reference fields (and same for "to"). This has been replaced with the clean model:
+
+  - `fromPath` (raw/custom) + `fromInternal` (single Link→Entry)
+  - `toPath` (raw/external) + `toInternal` (single Link→Entry)
+
+  Both internal fields are restricted via `linkContentType` validation to: page, article, articleType, person, tag, customType, tagType.
+
+  Updated:
+
+  - Migration `scripts/migrations/18-create-redirect-content-type.js` (now a clean create for the good model; delete any previous "Redirect" CT first if you ran the old multi-field version).
+  - `BaseRedirectSkeleton`, `baseRedirectConverter`, and `IRedirect` (provenance is now `fromInternal`/`toInternal` as `IInternalLink`).
+  - `UrlCalculators` now requires a `tagType(slug)` function (to support selecting tag type indexes as redirect targets).
+  - Added `baseTagTypeLinkConverter`, registered the resolver, extended `BaseLink` / `InternalType` / exported `ITagTypeLink` + guard.
+
+  Docs and the `se-marketing-sites-redirects` skill have been updated with the new CT shape, help text guidance, and testing steps.
+
+  Consumers will need to implement `tagType` in their urlCalculators (and pass it through `createBaseConverterContext`) to select Tag Type entries in redirects and to satisfy the updated type.
+
+  The runtime redirect map, middleware, and `buildRedirectMap` behaviour are unchanged.
+
 ## 1.1.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@se-studio/skills",
-  "version": "1.1.0",
+  "version": "1.1.3",
   "description": "SE Studio agent skills for marketing site development with Contentful CMS",
   "repository": {
     "type": "git",

package/skills/se-marketing-sites-redirects/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: se-marketing-sites-redirects
-description: "Add support for editor-managed URL redirects using a dedicated redirect content type + the proven A/B-style rebuild pattern (webhook to Vercel deploy hook, build bakes a static map). Includes the two official migration scripts (create CT, remove legacy redirectTo fields)."
+description: "Add support for editor-managed URL redirects using a dedicated redirect content type + the proven A/B-style rebuild pattern (webhook to Vercel deploy hook, build bakes a static map). Includes the official migration script (create the clean CT with fromInternal/toInternal single-ref pickers)."
 ---
 
 # SE Marketing Sites — Redirects (rebuild pattern)
@@ -8,7 +8,7 @@ description: "Add support for editor-managed URL redirects using a dedicated red
 This skill adds the ability for **non-technical content editors** to manage redirects entirely from Contentful.
 
 **Core idea (matches how your A/B tests already work):**
-- Editors create `redirect` entries (they can **pick** existing Pages/Articles/etc. from reference fields or type raw paths).
+- Editors create `redirect` entries (they can **pick** existing Pages/Articles/etc. via the single From/To internal pickers or type raw paths).
 - On publish, a Contentful webhook calls your Vercel **Deploy Hook**.
 - The next build fetches the current redirects (via the normal CDA helpers), runs `buildRedirectMap`, and writes a tiny static file.
 - Your `middleware.ts` imports that file and does the redirect **synchronously with zero runtime cost**.
@@ -16,33 +16,32 @@ This skill adds the ability for **non-technical content editors** to manage redi
 
 A faster "seconds" path (Edge Config) is explicitly **not** included in v1 per product direction — the model and helpers are forward-compatible if you add it later.
 
-## 1. Run the migrations (create the content type + clean up legacy)
+## 1. Run the migration (create the content type)
 
-The repo contains two official migrations:
+The repo contains the official migration:
 
 ```bash
-# 1. Create the new redirect content type (with great help text for editors)
+# Create the redirect content type (clean fromPath + fromInternal / toPath + toInternal model)
 node scripts/migrations/18-create-redirect-content-type.js
-
-# 2. (Later, when you are ready) Remove the old per-page redirectTo fields
-node scripts/migrations/19-remove-redirectTo-fields.js
 ```
 
-Run them with the Contentful CLI (or the contentful-cms package tools) and the usual `CONTENTFUL_SPACE_ID` + `CONTENTFUL_MANAGEMENT_TOKEN` + environment.
+Run it with the Contentful CLI (or the contentful-cms package tools) and the usual `CONTENTFUL_SPACE_ID` + `CONTENTFUL_MANAGEMENT_TOKEN` + environment.
+
+If you previously created a Redirect CT using an older multi-field version of the migration, **delete the "Redirect" content type first**, then re-run to get the clean single-ref model.
 
-After the create migration you will have a new content type called **Redirect**.
+After running you will have a new (or repaired) content type called **Redirect**.
 
 ## 2. The Redirect content type (what editors see)
 
 Key fields (all documented with help text in the migration):
 
 **From (source)**
-- `fromPath` (raw path) — editors type `/old-url/` when they are not using a picker.
-- `fromPage`, `fromArticle`, `fromArticleType`, `fromPerson`, `fromTag`, `fromCustomType` — reference pickers. When an editor picks one, the system automatically uses that item's current URL. This is the magic that makes it easy for non-technical people.
+- `fromPath` (raw path) — editors type `/old-url/` when they are not using the picker.
+- `fromInternal` (single reference picker) — restricted to page, article, articleType, person, tag, customType, tagType. When an editor picks one, the system automatically uses that item's current URL. This is the magic that makes it easy for non-technical people.
 
 **To (destination)**
 - `toPath` (raw path or full external `https://...` URL)
-- `toPage`, `toArticle`, ... — same reference pickers as above.
+- `toInternal` (single reference picker, same allowed types as fromInternal)
 
 **Other**
 - `statusCode` — dropdown: 301 (permanent — recommended), 302, 307, 308.
@@ -51,7 +50,7 @@ Key fields (all documented with help text in the migration):
 - `cmsLabel` — required internal label.
 
 **Editor guidance (the help text says this):**
-> For redirects **from** an existing CMS page or article, use the reference picker instead of typing the slug. Same for the destination. Only use the raw path fields for old/vanity URLs that no longer exist in the CMS or for external sites.
+> For redirects from existing CMS content, use the "From internal" / "To internal" picker instead of typing the slug. Only use the raw path fields for old/vanity URLs that no longer exist in the CMS or for external sites.
 
 The converter (`baseRedirectConverter`) resolves any chosen references into concrete `fromPath` / `to` strings at fetch time. The baked map only ever contains simple strings.
 
@@ -59,9 +58,9 @@ The converter (`baseRedirectConverter`) resolves any chosen references into conc
 
 The following are already in the packages:
 
-- `IRedirect` + `isRedirect` in `@se-studio/core-data-types`
+- `IRedirect` + `isRedirect` in `@se-studio/core-data-types` (now uses `fromInternal` / `toInternal`)
 - `baseRedirectConverter` + `BaseRedirectSkeleton`
-- `contentfulRedirectsRest` + `buildRedirectMap` + `getRedirectsWithErrors` / `getRedirectMap` (via `createAppHelpers`)
+- `contentfulRedirectsRest` + `buildRedirectMap` (now with robust self/cycle guards + normalization) + `getRedirectsWithErrors` / `getRedirectMap` (via `createAppHelpers`)
 - Revalidation tag `redirect` (so the existing webhook machinery knows about the new type)
 
 You only need to wire the **rebuild** side in your app.
@@ -175,6 +174,30 @@ export const config = {
 
 If you already have a `middleware.ts` for A/B or other things, just add the redirect check at the very top (before any other logic).
 
+### 4.2.1 Redirects and sitemaps
+
+When you create a redirect whose `from` (raw or resolved via internal picker) matches a URL that would otherwise be listed in your sitemap, that URL should generally be omitted from the sitemap (search engines should not be told to crawl a source that 301s away).
+
+The shared libraries now support this easily:
+
+- The `getSitemapEntries(...)` function returned by the marketing sitemap helper (when you configure `marketingSiteSitemap` in `createAppHelpers`) accepts an optional `redirectMap` in its options. When supplied, any entry whose URL is a redirect source is filtered out before the entries are returned to `buildSitemap`.
+- Standalone: `filterSitemapEntriesExcludingRedirects(entries, redirectMap)` (exported from `@se-studio/contentful-rest-api`) works on any `{ url: string }[]` list for custom flows.
+
+Recommended pattern (in `app/sitemap.ts` and the unindexed route):
+
+```ts
+import { getRedirectMap, getSitemapEntries } from '@/lib/cms-server';
+import { buildSitemap } from '@se-studio/core-ui';
+
+export default async function sitemap() {
+  const redirectMap = await getRedirectMap({});
+  const entries = await getSitemapEntries({ includeUnindexed: false, redirectMap });
+  return buildSitemap([() => Promise.resolve(entries)], { baseUrl, ... });
+}
+```
+
+Pure `fromPath` vanity redirects were already absent from sitemaps (no backing content entry). This mainly helps when you redirect *away from* live CMS pages/articles.
+
 ### 4.3 Webhook = Deploy Hook (the trigger)
 
 In Contentful → Settings → Webhooks, create (or reuse) a webhook that fires on:
@@ -191,15 +214,15 @@ That's it. Publish a redirect → Vercel starts a build → the generate step ru
 
 1. Run the create migration.
 2. In Contentful create a Redirect:
-   - Pick a real Page as "From Page".
-   - Type `/somewhere-else/` as "To path".
+   - Pick a real Page via the single "From internal" picker.
+   - Pick (or type) a destination via "To internal" or "To path".
    - Status 301, Active on.
 3. Publish.
 4. Watch the deploy hook fire a build in Vercel.
 5. After the build finishes: `curl -I https://your-site/from-page-url/` → 301 to the target.
 6. Also test a raw-path rule and an external URL.
 7. Edit the rule → republish → new build → new behaviour.
-8. (Optional) Run the remove migration and confirm the old `redirectTo` fields are gone.
+8. (Optional) If you also want to clean up legacy per-page `redirectTo` fields, run migration 19.
 
 ## 6. Preview / draft deployments
 
@@ -227,6 +250,8 @@ Then commit the updated `.agents/skills/...` (the monorepo keeps them in sync wi
 
 The `redirect` content type and the `buildRedirectMap` / `getRedirectMap` helpers are intentionally stable so a future faster path can consume the same data.
 
+`buildRedirectMap` automatically drops self-redirects (A → A after normalization) and any rules that participate in longer cycles, emitting a console warning for cycles during build/generate. Internal paths are normalized with a trailing `/` to match your urlCalculators and sitemap hrefs.
+
 ---
 
 **You now have editor-managed redirects that are as robust and low-surprise as your A/B tests, using only patterns that already exist in the codebase.**