BHDicaire

Pattern library

Governance rules

Use this page to add or audit a pattern page. Governance defines when a composition deserves a pattern; this page defines how the site records and renders it.

Pattern profile#

pattern_kind: "pattern"
pattern_category: "navigation"
pattern_status: "implemented"
pattern_components:
  - /docs/site-implementation/components/navigation/
  - /docs/site-implementation/components/language-toggle/
pattern_content:
  - menu configuration per language
pattern_accessibility:
  - visible keyboard focus
  - landmark label distinct from other navigation
pattern_implementation:
  partial:
    - layouts/partials/header.html
  css:
    - assets/css/site.css
  js:
    - assets/js/site.js

pattern_kind is always pattern. pattern_category identifies the recurring task, not a visual treatment. pattern_status is implemented, specified, or deprecated. Use pattern_components for the component documentation paths that make up the pattern; never repeat their implementation files in prose.

pattern_content records authoring or data requirements. pattern_accessibility records pattern-level expectations only—rules that emerge from the composition, not a copy of every component contract. pattern_implementation uses the same evidence-map mechanism names as interface manifests: partial, shortcode, layout, data, css, js, i18n, and configuration.

Page shape#

Write only the sections that help someone apply the pattern:

  1. Task — who needs to do what, and when this pattern is appropriate.
  2. Composition — the involved components and their responsibilities.
  3. Content and data — required configuration, editorial inputs, and empty or error states.
  4. Responsive behaviour — what changes at narrower and wider sizes.
  5. Accessibility — landmark, keyboard, focus, reading-order, and announcement behaviour created by the composition.
  6. Implementation — source-backed explanation only when it adds context beyond the manifest.
  7. Pattern manifest — the generated evidence record.

Migration recipe#

  1. Confirm the recurring user task and the boundary in Pattern library.
  2. Audit the existing implementation and components. Record only verified paths and real component documentation pages.
  3. Add a bilingual page pair under docs/site-implementation/patterns/; use the standard title, description, and updated-date front matter.
  4. Add the pattern_* fields, then render {{< pattern-manifest >}} before the accessibility section.
  5. Run npm run lint:patterns, then verify English and French output, internal links, keyboard behaviour, and responsive states before setting pattern_status: "implemented".

A pattern is specified—not implemented—until its task, component composition, and source evidence exist together.