@se-studio/skills 1.1.0 → 1.1.1

package/CHANGELOG.md

@@ -1,5 +1,31 @@
 # @se-studio/skills
 
+## 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.1",
   "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,7 +58,7 @@ 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`)
 - Revalidation tag `redirect` (so the existing webhook machinery knows about the new type)
@@ -191,15 +190,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