Configuration Reference

Configure the addrbookview.uk shell

addrbookview.uk is a static Astro + Starlight site with a config layer that controls visible labels, metadata, navigation, and the shared behavior readers see before they open any specific article.

astro.config.mjs

import { defineConfig } from "astro/config";
import starlight from "@astrojs/starlight";

export default defineConfig({
  integrations: [
    starlight({
      title: "addrbookview.uk",
    }),
  ],
});

This page is not a generic Starlight manual. It documents the config surfaces that matter when you are shaping addrbookview.uk as a research and publishing shell.

site identity

type: shared config values

Use the shared site config to control title, description, author labels, footer copy, and canonical-facing defaults. These values affect how the shell presents the site before a reader reaches any specific ranking or topic page.

metadata

type: shared config values

Metadata should describe the site as a signal research property, not a general docs template. The defaults should support:

• recognizable browser tab titles,
• coherent search snippets,
• stable Open Graph previews,
• and canonical references that point to https://addrbookview.uk.

logo

type: brand asset config

The logo shown in the navigation bar should reinforce the addrbookview.uk brand without changing the template structure. If the shell uses separate light and dark assets, keep both variants visually equivalent so the visible identity stays stable across themes.

table of contents

type: page-level navigation behavior

The table of contents matters because many pages on addrbookview.uk are longer than a normal landing page. Keep heading depth shallow enough that readers can orient quickly instead of parsing an over-detailed TOC.

navigation button

type: header CTA config

The top-right action should point to the current best starting path. Right now that means a clear entry action such as Start Here, not a generic template CTA.

sidebar

type: section map

The sidebar should mirror the actual information architecture. A useful mental model is:

• Start Here for orientation and first-read pages
• Coverage for rankings, topic briefs, and concrete page groups
• Reference for rules, methods, and publishing logic
• Operations for system-facing or workflow-facing material

Use short labels and keep them stable. Frequent sidebar renames make the site feel inconsistent even when routes do not change.

starlight({
  sidebar: [
    { label: "Home", link: "/" },
    {
      label: "Start Here",
      items: [
        "getting-started/introduction/overview",
        "getting-started/introduction/Quickstart",
        "getting-started/navigation",
      ],
    },
    {
      label: "Reference",
      autogenerate: { directory: "reference" },
    },
  ],
});

sorting and grouping

type: navigation behavior

Autogenerated groups are useful, but only if the directory names already reflect the right reader-facing order. If a page is important for onboarding or method trust, do not rely only on accidental filename sorting—shape the section labels and filenames intentionally.

translations

type: locale label config

If multilingual support remains enabled in the shell, translated labels should preserve meaning, not just literal wording. The current priority is still English-first clarity for addrbookview.uk.

content collections

type: schema-backed page organization

addrbookview.uk uses content collections to distinguish between page families such as docs, rankings, and other structured MDX entries. This matters because the shell is not just decorative—the collection layer determines how content is validated and surfaced.

menus and footer links

type: JSON-driven shell config

The visible shell depends on a small set of JSON files in src/config/:

• config.json for site identity and footer text
• menu.en.json for header navigation
• sidebar.json for docs section naming
• social.json for external/footer channels

When the shell looks outdated, audit these files before assuming the content pages are wrong.

public verification cues

type: deployment-facing reference facts

When a page is expected to represent the latest content, verify the public route rather than trusting only local source files. Practical checks include:

• the public title and description,
• the expected page route under https://addrbookview.uk/...,
• visible shell labels such as Start Here,
• and page-level markers or updated copy that prove the build output is current.

freshness markers

type: page-level metadata signal

Some pages carry deploy or freshness indicators so the publishing chain can distinguish old public HTML from fresh output. These markers should be treated as verification signals, not decorative content.

editing and change control

type: workflow rule

When changing configuration, prefer the smallest possible edit that updates meaning without changing template structure. For this site, shell consistency matters more than adding more knobs.

Practical configuration checklist

Use this sequence when you update visible site configuration:

1. edit the relevant JSON or MDX-backed shell file,
2. rebuild the site,
3. restart the static-serving process,
4. check the target public route,
5. verify that the new labels and metadata are actually live.

What this reference covers

This reference is mainly about the shell and method layer of addrbookview.uk, not about every possible Starlight feature. If you are reviewing the site, focus on these questions:

• Does the shell explain what the site is?
• Do sidebar and header labels match the page groups?
• Are public routes and visible labels coherent?
• Can a reader tell where rankings end and reference logic begins?
• Are build and freshness cues visible when needed?

Common mistakes

Treating template labels as harmless

Template wording leaks product meaning. If a label still says DocKit, the reader immediately feels the site is unfinished.

Changing structure when wording is enough

For this migration stage, the goal is to keep the template structure and replace only the meaning layer.

Verifying only local source

A local file being correct does not prove the public site is correct. Always verify the built and public route.

Related reference surfaces

Use these pages together:

• Overview
• Global Configuration
• Plugins Reference
• Homepage