news: enable categories taxonomy and term pages in the news bundle #129

Closed
opened 2026-07-19 10:13:33 +02:00 by dominik.polakovics · 1 comment

This was generated by AI during triage.

Split out of #77 (News v2 categories). Second slice of the stack: Hugo-side taxonomy enablement and term pages for the news feature bundle. Independent of the multiselect field type — term pages render from front matter, which tests can author directly.

Decision record from triage on #77: full Hugo-taxonomy scope, categories only, vocabulary curated in sidecar options, work split into stacked issues.

Agent brief follows in the comments.

> *This was generated by AI during triage.* Split out of #77 (News v2 categories). Second slice of the stack: Hugo-side taxonomy enablement and term pages for the news feature bundle. Independent of the multiselect field type — term pages render from front matter, which tests can author directly. Decision record from triage on #77: full Hugo-taxonomy scope, **categories only**, vocabulary **curated in sidecar options**, work split into stacked issues. Agent brief follows in the comments.
Author
Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: harness add news enables a categories Hugo taxonomy on the site, and the news bundle ships taxonomy/term list templates.

Current behavior:
The scaffolded site disables Hugo's taxonomy and term page kinds via disableKinds in hugo.toml, and no taxonomy or term templates exist anywhere in the theme or bundles. The news feature bundle (harness add news) vendors news page types, layouts, and RSS onto a site, and already mutates hugo.toml through the add command's feature-step mechanism (it stamps buildFuture = true so future-dated items render). News items carry no category metadata.

Desired behavior:
Adding the news feature configures the site for a single categories taxonomy and renders working term pages:

  • A new news feature step updates the site's hugo.toml: declares the categories taxonomy and removes taxonomy and term from disableKinds. It must be idempotent (safe to run on a site that already has it), in the style of the existing buildFuture step. Sites that never add the news feature keep taxonomy kinds disabled.
  • The bundle vendors two new layout templates:
    • a term template: all non-draft news items carrying that category, date-descending, paginated the same way as the news section list (reuse the existing pager partial);
    • a taxonomy overview template: the list of categories in use, each with its item count, linking to its term page.
  • With news items whose front matter carries a categories list (hand-authored for now — the editor field is a separate stacked issue), the built site produces the /categories/ overview and /categories/<term>/ pages with the right items. Draft items are excluded, matching the news list's draft handling.
  • The feature's post-add "next steps" guidance mentions that categories are available and how items opt in (front-matter list until the editor field lands).

Key interfaces:

  • The add command's feature-step mechanism (the per-feature step list) — a new step alongside the buildFuture one
  • The hugo.toml config shape: disableKinds and the taxonomies table
  • The news bundle's layout set — new taxonomy and term templates, reusing the pager partial
  • The theme/news integration tests and their fixture site — extended with categorized fixture items to assert term-page rendering

Acceptance criteria:

  • harness add news on a fresh site yields a hugo.toml with the categories taxonomy declared and taxonomy/term no longer in disableKinds; running add twice does not duplicate or corrupt the config
  • With fixture news items carrying categories front matter, the built site contains a /categories/ overview and per-term pages listing exactly the matching items, date-descending, drafts excluded
  • Term pages paginate like the news section list
  • A scaffolded site that never adds the news feature still has taxonomy/term kinds disabled
  • Tests cover both the feature step (config mutation, idempotence) and the rendered term/overview pages

Out of scope:

  • The editor-facing categories field on news items and the news-list category filter (separate stacked issue, blocked on this one and on the multiselect field type)
  • The multiselect field type itself
  • Tags or any second taxonomy
  • RSS output for term pages
> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** `harness add news` enables a `categories` Hugo taxonomy on the site, and the news bundle ships taxonomy/term list templates. **Current behavior:** The scaffolded site disables Hugo's `taxonomy` and `term` page kinds via `disableKinds` in `hugo.toml`, and no taxonomy or term templates exist anywhere in the theme or bundles. The news feature bundle (`harness add news`) vendors news page types, layouts, and RSS onto a site, and already mutates `hugo.toml` through the add command's feature-step mechanism (it stamps `buildFuture = true` so future-dated items render). News items carry no category metadata. **Desired behavior:** Adding the news feature configures the site for a single `categories` taxonomy and renders working term pages: - A new news feature step updates the site's `hugo.toml`: declares the `categories` taxonomy and removes `taxonomy` and `term` from `disableKinds`. It must be idempotent (safe to run on a site that already has it), in the style of the existing buildFuture step. Sites that never add the news feature keep taxonomy kinds disabled. - The bundle vendors two new layout templates: - a **term** template: all non-draft news items carrying that category, date-descending, paginated the same way as the news section list (reuse the existing pager partial); - a **taxonomy overview** template: the list of categories in use, each with its item count, linking to its term page. - With news items whose front matter carries a `categories` list (hand-authored for now — the editor field is a separate stacked issue), the built site produces the `/categories/` overview and `/categories/<term>/` pages with the right items. Draft items are excluded, matching the news list's draft handling. - The feature's post-add "next steps" guidance mentions that categories are available and how items opt in (front-matter list until the editor field lands). **Key interfaces:** - The add command's feature-step mechanism (the per-feature step list) — a new step alongside the buildFuture one - The `hugo.toml` config shape: `disableKinds` and the `taxonomies` table - The news bundle's layout set — new taxonomy and term templates, reusing the pager partial - The theme/news integration tests and their fixture site — extended with categorized fixture items to assert term-page rendering **Acceptance criteria:** - [ ] `harness add news` on a fresh site yields a `hugo.toml` with the `categories` taxonomy declared and `taxonomy`/`term` no longer in `disableKinds`; running add twice does not duplicate or corrupt the config - [ ] With fixture news items carrying `categories` front matter, the built site contains a `/categories/` overview and per-term pages listing exactly the matching items, date-descending, drafts excluded - [ ] Term pages paginate like the news section list - [ ] A scaffolded site that never adds the news feature still has taxonomy/term kinds disabled - [ ] Tests cover both the feature step (config mutation, idempotence) and the rendered term/overview pages **Out of scope:** - The editor-facing categories field on news items and the news-list category filter (separate stacked issue, blocked on this one and on the multiselect field type) - The multiselect field type itself - Tags or any second taxonomy - RSS output for term pages
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Cloonar/deckle#129
No description provided.