PLAN

Ze Wiki -- Detailed Plan

This file is the source of truth for what the Ze wiki should contain, page by page. It is intended to be read by Thomas (to agree the structure) and by an implementer agent (to actually create the pages). The companion file IMPLEMENTATION.md explains how to execute this plan.

1. Goals

The wiki must serve four audiences without making any of them feel second-class:

1. Curious operator ("what is this thing, should I care?") -- needs a fast yes/no within one page.
2. ExaBGP user evaluating Ze -- needs migration story, compatibility notes, "what is the same / what changes".
3. New Ze operator -- needs install, first peer up, day-2 commands, troubleshooting.
4. Plugin author / contributor -- needs architecture, plugin SDK, contribution workflow.

The structure is audience-led sections, dispatch landing page, separate Blueprints to match what Ze actually is: a programmable BGP engine and event bus, not a network distro.

2. Decisions taken (override here if you disagree)

#	Decision	Reasoning
D1	One page per plugin, grouped by the six categories from main/README.md	Findability, SEO, future per-plugin changelogs.
D2	Chaos testing is its own top-level section, not buried under Development	It is a Ze differentiator. Visibility is the point.
D3	ExaBGP migration lives under "First Steps", not under Blueprints	Migrators are the primary current audience.
D4	CLI, Web UI, Looking Glass, MCP, REST API all live under a single "Interfaces" top-level section	They are five surfaces over the same engine. Grouping them helps the reader build the right mental model.
D5	Plugin development is its own top-level section, not a sub-page of Plugins	Two distinct audiences (operators vs authors), so they get distinct sidebars.
D6	Wiki uses subdirectories, not flat hyphenated names	Codeberg/Gitea wiki supports nested paths. The plan has too many pages for a flat layout to stay navigable.
D7	Each section has an index.md page that links to its children with a one-line description	Lets readers browse without depending on the sidebar.
D8	The wiki does not duplicate main/docs/ -- it links to or curates from it. The implementer should copy the relevant in-tree doc, edit for tone and audience, and mark the canonical source at the bottom of the page	Avoids two sources of truth drifting apart.

3. Top-level structure

Home.md                  Landing page (card grid + zeledon mascot)
_Sidebar.md              Navigation sidebar (Gitea wiki convention)
_Footer.md               Footer (license, links)

about/                   What Ze is, why it exists, how it is built
first-steps/             Install, quick start, ExaBGP migration, first peer
configuration/           YANG model, BGP, interfaces, FIB, RPKI, fleet
operation/               Day-2: show, monitor, log, upgrade, restart
interfaces/              CLI, Web UI, Looking Glass, MCP, REST API
plugins/                 Per-plugin reference, grouped by category
plugin-development/      How to write a plugin (Go and external)
chaos-testing/           ze-chaos orchestrator and dashboard
blueprints/              End-to-end worked examples
development/             Building, repo layout, testing, contributing
reference/               Command reference, feature matrix, comparison, glossary

4. Page-by-page detail

For each page:

• Path -- where the file lives in the wiki repo.
• Purpose -- one sentence: who reads this and why.
• Outline -- what sections the page must cover.
• Source -- which file(s) under main/docs/ (or elsewhere) to draw from. -- means write fresh.
• Status -- existing if a draft already lives in main/docs/ and only needs adaptation, new if it must be written from scratch, stub if a placeholder is acceptable for v1.

4.1 Landing page

Home.md

• Purpose: First impression. A visitor must understand within 10 seconds what Ze is, who it is for, and where to click next.
• Outline:
  • Tagline (one sentence: "Ze turns a Linux server into a programmable network device").
  • Six-card grid: Try Ze | Install | Configure | Plugins | Automate | Contribute.
  • Status banner: "Pre-Alpha. APIs and config syntax will change."
  • Three-up screenshot strip: CLI, Web UI, Looking Glass.
  • Footer paragraph: license, repo link, ExaBGP relationship.
• Source: existing wiki/Home.md for tagline; main/README.md for component table; reuse images already in wiki/images/.
• Status: existing (rewrite to card-grid form).

_Sidebar.md

• Purpose: Persistent navigation.
• Outline: Hierarchical list of every section index. Top level = section name. Nested = page titles. Plugins category gets a single expandable entry, not 25 lines.
• Source: --
• Status: new.

_Footer.md

• Purpose: Per-page footer.
• Outline: License (AGPL-3.0), Codeberg link, Discord link, "Edit this page" link.
• Source: --
• Status: new.

4.2 About

about/index.md

• Purpose: Section index with one-line links to children.
• Status: new.

about/what-is-ze.md

• Purpose: 5-minute read for a curious operator. Answers "what is this and why does it exist".
• Outline: One-paragraph definition, the engine + plugins model in three sentences, what Ze is not (not a distro, not a router OS, not a Quagga fork), the headline features, how it relates to ExaBGP.
• Source: main/docs/why-ze.md, main/README.md intro paragraphs.
• Status: existing.

about/why-ze.md

• Purpose: The longer essay. Reasons the project exists, problems with existing daemons, design choices.
• Outline: Existing why-ze.md content, lightly edited for the wiki audience.
• Source: main/docs/why-ze.md.
• Status: existing.

about/architecture.md

• Purpose: Mental model of the engine. Bus, supervisor, config provider, plugin manager.
• Outline: Diagram (main/docs/ze-architecture.svg), component list (from README's Components table), how a BGP UPDATE flows through the system, where plugins hook in.
• Source: main/docs/architecture/overview.md, main/docs/architecture/system-architecture.md, main/docs/architecture/core-design.md, main/docs/ze-architecture.svg.
• Status: existing (heavy condensation: the in-tree docs are 40K+, the wiki page should be 1500 words max with a "deep dive" link).

about/history.md

• Purpose: Where Ze came from. ExaBGP lineage, AI-assisted development story, project timeline.
• Outline: ExaBGP -> Ze rationale, the AI-assisted angle (one honest paragraph), the "Pre-Alpha" status, what is done and what is next.
• Source: main/README.md "AI-Assisted Project" section, main/docs/exabgp/exabgp-differences.md.
• Status: new.

about/status.md

• Purpose: Honest status. What works, what is broken, what is planned. Mirror of main/docs/guide/status.md.
• Outline: Feature matrix (working / partial / planned / not started), known limitations, breaking-change policy.
• Source: main/docs/guide/status.md, main/docs/features.md.
• Status: existing.

4.3 First Steps

first-steps/index.md

• Purpose: Section index.
• Status: new.

first-steps/install.md

• Purpose: Get a working ze binary on a Linux box.
• Outline: Prerequisites (Go 1.25+, Linux kernel features), the four install paths (build from source, container, prebuilt binary if/when available, package), verification (ze version).
• Source: main/README.md Quick Start section, main/Makefile for build targets.
• Status: existing (extracted from README).

first-steps/quick-start.md

• Purpose: First peer up in five minutes.
• Outline: ze init, write a minimal config (one peer, one prefix), ze start, verify with ze show peers, kill and restart with state preserved.
• Source: main/docs/guide/quickstart.md.
• Status: existing.

first-steps/exabgp-migration.md

• Purpose: Convert an ExaBGP setup to Ze. Front-and-centre because it is the primary current audience.
• Outline: ze config migrate <exabgp.conf>, what gets converted, what does not, the ze exabgp plugin bridge for unconverted scripts, side-by-side config example, gotchas and known divergences.
• Source: main/docs/guide/exabgp-migration.md, main/docs/config-migration.md, main/docs/exabgp/exabgp-differences.md.
• Status: existing.

first-steps/cli-tour.md

• Purpose: Five-minute tour of the interactive CLI: edit, diff, commit, rollback. Read-once, the deeper reference is in interfaces/cli.md.
• Outline: Connect via SSH, enter config mode, add a peer, diff, commit, rollback, commit confirmed, exit.
• Source: main/docs/guide/cli.md, main/docs/architecture/cli/.
• Status: existing.

first-steps/web-ui-tour.md

• Purpose: Five-minute tour of the web UI. Same shape as the CLI tour.
• Outline: Open browser, login, navigate the column view, draft a change, review diff, commit.
• Source: main/docs/features/web-interface.md, main/docs/architecture/web-interface.md.
• Status: existing.

4.4 Configuration

configuration/index.md

• Purpose: Section index.
• Status: new.

configuration/overview.md

• Purpose: How configuration works in Ze conceptually. Read once before editing anything.
• Outline: YANG-modeled, validated, atomic commit, rollback, draft sessions per user, hot reload, no daemon restart.
• Source: main/docs/features/configuration.md, main/docs/guide/configuration.md.
• Status: existing.

configuration/yang-model.md

• Purpose: Reading and understanding the YANG schema that drives every config field, CLI prompt, and Web UI form.
• Outline: Where the schemas live, how they map to CLI paths, how to view a schema for a node, plugin schemas, validation errors.
• Source: main/docs/architecture/config/, main/docs/plugin-development/schema.md.
• Status: existing.

configuration/editor-workflow.md

• Purpose: Edit / diff / commit / rollback workflow in detail.
• Outline: The five operations, commit confirmed and the rollback timer, multi-user draft isolation, conflict resolution.
• Source: main/docs/guide/config-editor.md, main/docs/guide/config-reload.md.
• Status: existing.

configuration/archive-and-rollback.md

• Purpose: How Ze keeps every committed config and how to recover from a bad change.
• Outline: Archive layout, listing past commits, diffing two commits, rolling back N commits, restoring from a specific commit.
• Source: main/docs/guide/config-archive.md.
• Status: existing.

configuration/system.md

• Purpose: System-level config: hostname, users, SSH, TLS, listeners, logging targets.
• Outline: One section per system subtree.
• Source: main/docs/guide/configuration.md (system sections), main/docs/guide/logging.md.
• Status: existing.

configuration/bgp/index.md

• Purpose: Sub-section index for BGP configuration.
• Status: new.

configuration/bgp/peers.md

• Purpose: Configure a BGP peer end to end.
• Outline: Peer types (eBGP, iBGP, RR client), required fields, capability negotiation, password and TCP-MD5, MD5 vs TCP-AO, listen vs connect, multihop.
• Source: main/docs/guide/configuration.md (BGP), main/docs/features/bgp-protocol.md.
• Status: existing.

configuration/bgp/policies.md

• Purpose: Filter and transform routes inbound and outbound.
• Outline: Match clauses, action clauses, prefix lists, community lists, AS-path lists, ordering, debugging policy with show route policy-trace.
• Source: main/docs/guide/configuration.md (policy), plugins bgp-rs, bgp-filter-community.
• Status: existing.

configuration/bgp/address-families.md

• Purpose: Enable address families on a peer.
• Outline: ipv4 unicast, ipv6 unicast, ipv4/ipv6 multicast, link-state, flowspec, EVPN, VPNv4, VPNv6, labeled-unicast. Which are built in vs plugin-provided.
• Source: main/docs/features/bgp-protocol.md, plugin docs for non-built-in families.
• Status: existing.

configuration/bgp/add-path.md

• Purpose: BGP Add-Path (RFC 7911).
• Source: main/docs/guide/add-path.md.
• Status: existing.

configuration/bgp/graceful-restart.md

• Purpose: BGP Graceful Restart and Long-Lived GR.
• Source: main/docs/guide/graceful-restart.md.
• Status: existing.

configuration/bgp/bgp-role.md

• Purpose: BGP Role (RFC 9234).
• Source: main/docs/guide/bgp-role.md.
• Status: existing.

configuration/bgp/route-reflection.md

• Purpose: Configure Ze as a route reflector.
• Source: main/docs/guide/route-reflection.md.
• Status: existing.

configuration/bgp/route-injection.md

• Purpose: Inject routes from a script or external program.
• Source: main/docs/guide/route-injection.md.
• Status: existing.

configuration/bgp/redistribution.md

• Purpose: Redistribute between BGP and other sources.
• Source: main/docs/guide/redistribution.md.
• Status: existing.

configuration/interfaces.md

• Purpose: Configure Linux network interfaces through Ze.
• Outline: Interface types supported, addresses, MTU, link state, DHCP, static, bonding, VLAN. The plugins under internal/plugins/iface* are what implements this.
• Source: main/docs/features/interfaces.md.
• Status: existing.

configuration/fib.md

• Purpose: Programming the Linux FIB and (optionally) a P4 dataplane.
• Outline: fibkernel plugin (default), fibp4 plugin (experimental), sysrib, route selection, ECMP.
• Source: main/docs/architecture/route-selection.md, plugin source under internal/plugins/fibkernel and internal/plugins/fibp4.
• Status: existing.

configuration/rpki.md

• Purpose: Validate routes against RPKI.
• Source: main/docs/guide/rpki.md.
• Status: existing.

configuration/fleet.md

• Purpose: Manage multiple Ze instances from one config.
• Source: main/docs/guide/fleet-config.md, main/docs/architecture/fleet-config.md, main/docs/features/fleet-management.md.
• Status: existing.

4.5 Operation

operation/index.md

• Purpose: Section index.
• Status: new.

operation/starting-and-stopping.md

• Purpose: ze start, ze stop, systemd unit, restart with state preservation.
• Source: main/docs/guide/operations.md.
• Status: existing.

operation/show-commands.md

• Purpose: All show commands for operators. Pointer to the full reference for the long list.
• Outline: The 10 most-used show commands with example output, then a link to reference/command-reference.md.
• Source: main/docs/guide/command-reference.md, main/docs/features/cli-commands.md.
• Status: existing.

operation/monitoring.md

• Purpose: Watch session state and route counts in real time.
• Source: main/docs/guide/monitoring.md.
• Status: existing.

operation/logging.md

• Purpose: Log levels, targets, structured fields, log forwarding.
• Source: main/docs/guide/logging.md.
• Status: existing.

operation/operational-reports.md

• Purpose: The reports Ze produces for offline analysis.
• Source: main/docs/guide/operational-reports.md.
• Status: existing.

operation/healthcheck.md

• Purpose: Liveness, readiness, peer health endpoints.
• Source: main/docs/guide/healthcheck.md.
• Status: existing.

operation/mrt-analysis.md

• Purpose: Capture and replay MRT files.
• Source: main/docs/guide/mrt-analysis.md.
• Status: existing.

operation/upgrade-and-restart.md

• Purpose: How to upgrade Ze without dropping sessions. Graceful restart, persisted RIB, hand-over.
• Source: main/docs/guide/operations.md, main/docs/guide/graceful-restart.md, plugin bgp-persist.
• Status: existing.

4.6 Interfaces

interfaces/index.md

• Purpose: Section index. Explains the "five surfaces" mental model: CLI, Web UI, Looking Glass, MCP, REST API.
• Status: new.

interfaces/cli.md

• Purpose: Full CLI reference. Modes, history, completion, scripting, output formats.
• Source: main/docs/guide/cli.md, main/docs/architecture/cli/, main/docs/features/cli-commands.md.
• Status: existing.

interfaces/web-ui.md

• Purpose: Full Web UI reference. Layout, draft sessions, diffing, who-is-editing-what indicators, accessibility.
• Source: main/docs/guide/web-interface.md, main/docs/architecture/web-interface.md, main/docs/architecture/web-components.md.
• Status: existing.

interfaces/looking-glass.md

• Purpose: Public looking glass: peer dashboard, route lookup, AS-path topology graph.
• Outline: How to enable, what queries it supports, how to expose it publicly, Birdwatcher API for Alice-LG, the SVG topology renderer.
• Source: main/docs/guide/looking-glass.md, main/docs/features/looking-glass.md.
• Status: existing.

interfaces/mcp.md

• Purpose: MCP server for AI assistants. How to expose Ze to Claude / OpenAI / local tools.
• Source: main/docs/features/mcp-integration.md, main/docs/guide/mcp/.
• Status: existing.

interfaces/rest-api.md

• Purpose: HTTPS REST API for automation that does not want to use MCP or SSH.
• Source: main/docs/features/api-commands.md, main/docs/architecture/api/, main/docs/architecture/hub-api-commands.md.
• Status: existing.

interfaces/introspection.md

• Purpose: Self-describing commands: ze help --ai, schema discovery, command listing.
• Source: main/docs/features/introspection.md, main/docs/features/ai-first.md.
• Status: existing.

4.7 Plugins

plugins/index.md

• Purpose: Section index. Plugin model in three paragraphs, then a table linking to every plugin grouped by category.
• Outline: What a plugin is, the six categories, how plugins ship (built in vs external), how to enable / disable a plugin.
• Source: main/docs/features/plugins.md, main/docs/guide/plugins.md.
• Status: existing.

plugins/storage/

One page per plugin:

• bgp-rib.md -- the main RIB store.
• bgp-adj-rib-in.md -- per-peer adj-RIB-in.
• bgp-persist.md -- on-disk persistence across restarts.

Each page must include: purpose, configuration (YANG path + example), behavior, interactions with other plugins, source pointer.

• Source: plugin code under main/internal/component/bgp/, main/internal/component/managed/, plus any per-plugin notes in main/docs/guide/plugins.md.
• Status: stub for v1, fill in iteratively.

plugins/policy/

• bgp-rs.md -- routing policy DSL.
• bgp-filter-community.md -- community-based filtering.
• bgp-role.md -- the protocol-level Role plugin (the user-facing config story is under configuration/bgp/bgp-role.md).

plugins/resilience/

• bgp-gr.md -- Graceful Restart.
• bgp-watchdog.md -- session watchdog.
• bgp-route-refresh.md -- RFC 2918 Route Refresh.

plugins/validation/

• bgp-rpki.md -- RPKI validator client.
• bgp-rpki-decorator.md -- attaches validation state to routes.

plugins/capabilities/

• bgp-aigp.md -- Accumulated IGP metric.
• bgp-hostname.md -- FQDN capability.
• bgp-llnh.md -- Long-Lived Next-Hop.
• bgp-softver.md -- software version capability.

plugins/address-families/

• bgp-nlri-vpn.md
• bgp-nlri-evpn.md
• bgp-nlri-flowspec.md
• bgp-nlri-ls.md -- link-state.
• bgp-nlri-labeled.md
• bgp-nlri-vpls.md
• bgp-nlri-mvpn.md
• bgp-nlri-rtc.md -- route target constrain.
• bgp-nlri-mup.md -- mobile user plane.

plugins/infrastructure/

(These live under main/internal/plugins/ rather than internal/component/, but they are plugins by the same definition.)

• fibkernel.md -- program the Linux FIB via netlink.
• fibp4.md -- experimental P4 dataplane.
• ifacedhcp.md -- DHCP client for managed interfaces.
• ifacenetlink.md -- netlink-driven interface manager.
• sysrib.md -- system RIB shared between protocols.

4.8 Plugin development

plugin-development/index.md

• Purpose: Section index. Two paths: write a Go plugin (linked into Ze) or an external plugin (any language, IPC over a defined protocol).
• Status: existing.
• Source: main/docs/plugin-development/README.md.

plugin-development/go-plugins.md

• Purpose: Write an in-tree Go plugin.
• Outline: Skeleton, registration, lifecycle, schema, handlers, tests.
• Source: main/docs/plugin-development/handlers.md, main/docs/plugin-development/commands.md.
• Status: existing.

plugin-development/external-plugins.md

• Purpose: Write a plugin in another language.
• Outline: How to launch, how Ze discovers it, the IPC protocol, the SDK.
• Source: main/docs/plugin-development/protocol.md.
• Status: existing.

plugin-development/yang-schema.md

• Purpose: Write the YANG schema for your plugin's config.
• Source: main/docs/plugin-development/schema.md.
• Status: existing.

plugin-development/handlers.md

• Purpose: Event handler patterns and the bus message types.
• Source: main/docs/plugin-development/handlers.md.
• Status: existing.

plugin-development/commands.md

• Purpose: Add custom CLI / API commands from a plugin.
• Source: main/docs/plugin-development/commands.md.
• Status: existing.

plugin-development/testing.md

• Purpose: Testing your plugin in isolation and against a running Ze.
• Source: main/docs/plugin-development/testing.md.
• Status: existing.

4.9 Chaos testing

chaos-testing/index.md

• Purpose: Section index. What ze-chaos is, why it exists, what kinds of bugs it catches.
• Source: main/docs/guide/chaos-testing.md, main/docs/architecture/chaos-web-dashboard.md.
• Status: existing.

chaos-testing/scenarios.md

• Purpose: Write a chaos scenario file. Trigger types, fault injectors, assertions.
• Source: main/docs/guide/chaos-testing.md.
• Status: existing.

chaos-testing/dashboard.md

• Purpose: The web dashboard. Convergence histograms, property verification, replay.
• Outline: Use the existing screenshots in wiki/images/chaos-dashboard-*.png.
• Source: main/docs/architecture/chaos-web-dashboard.md.
• Status: existing.

chaos-testing/property-verification.md

• Purpose: How Ze verifies that protocol-level invariants hold across faults.
• Source: main/internal/chaos/ source comments, main/docs/architecture/chaos-web-dashboard.md.
• Status: stub for v1.

4.10 Blueprints

End-to-end worked examples. Each page must contain: scenario description, network diagram, full config, verification steps, "what could go wrong".

blueprints/index.md

• Purpose: Section index.
• Status: new.

blueprints/route-server-at-an-ixp.md

• Purpose: Run Ze as an IXP route server.
• Outline: Topology, peer config, route reflector vs route server, policy, looking glass exposure, RPKI integration.
• Source: write fresh, draw on main/docs/guide/route-reflection.md.
• Status: new.

blueprints/transit-edge-with-rpki.md

• Purpose: A transit-customer edge router with RPKI validation, BGP Role, and prefix limits.
• Source: write fresh.
• Status: new.

blueprints/public-looking-glass.md

• Purpose: Stand up a public looking glass for your AS.
• Outline: TLS, auth, what to expose and what not to, integration with Alice-LG via the Birdwatcher API.
• Source: write fresh, drawing on main/docs/guide/looking-glass.md.
• Status: new.

blueprints/exabgp-migration-walkthrough.md

• Purpose: A complete worked migration of a non-trivial ExaBGP setup.
• Source: write fresh, drawing on main/docs/guide/exabgp-migration.md and main/docs/exabgp/exabgp-comparison-report.md.
• Status: new.

blueprints/flowspec-injection.md

• Purpose: Inject BGP Flowspec rules from a script for DDoS mitigation.
• Source: write fresh, plugin bgp-nlri-flowspec.
• Status: stub for v1.

blueprints/chaos-tested-peering.md

• Purpose: Set up a peering session and verify it survives a battery of chaos scenarios.
• Source: write fresh.
• Status: stub for v1.

blueprints/as-path-topology.md

• Purpose: Use the looking glass topology graph to visualise a real network's AS paths.
• Source: write fresh, screenshots already in wiki/images/looking-glass-route-search.png.
• Status: stub for v1.

4.11 Development

development/index.md

• Purpose: Section index. Audience: people writing Go code in the Ze repo.
• Status: new.

development/building.md

• Purpose: Build Ze from source. Targets, prerequisites, common Make targets.
• Source: main/Makefile, main/CONTRIBUTING.md.
• Status: new.

development/repo-layout.md

• Purpose: Tour of the repo. What lives in cmd/, internal/, pkg/.
• Source: write fresh by reading the repo. Mirror main/docs/architecture/system-architecture.md.
• Status: new.

development/coding-standards.md

• Purpose: Style, linting, error handling, naming.
• Source: main/CLAUDE.md, main/CONTRIBUTING.md.
• Status: new.

development/testing.md

• Purpose: How to run unit, functional, fuzz, and chaos tests.
• Source: main/docs/functional-tests.md, main/docs/architecture/testing/, main/docs/ci-test-coverage.md.
• Status: existing.

development/debugging.md

• Purpose: Debugging tools, log levels, traces, dumps.
• Source: main/docs/debugging-tools.md, main/docs/architecture/debugging/.
• Status: existing.

development/ci.md

• Purpose: CI matrix, lints, what to expect when you open a PR.
• Source: main/docs/ci-test-coverage.md.
• Status: existing.

development/rfc-implementation.md

• Purpose: How RFCs are tracked and implemented in Ze.
• Source: main/docs/contributing/rfc-implementation-guide.md.
• Status: existing.

development/contributing.md

• Purpose: Contribution workflow. Issues, PRs, CLA, code review.
• Source: main/CONTRIBUTING.md, main/CLA.md.
• Status: existing.

development/claude-code.md

• Purpose: For contributors using Claude Code: project-specific slash commands and conventions.
• Source: main/docs/claude-code-cheatsheet.md.
• Status: existing.

4.12 Reference

reference/index.md

• Purpose: Section index. "Look here when you need an exact answer."
• Status: new.

reference/command-reference.md

• Purpose: Every CLI and API command, flags, output format. The long one.
• Source: main/docs/guide/command-reference.md (mirror, do not duplicate).
• Status: existing.

reference/feature-inventory.md

• Purpose: Every protocol, capability, attribute, and address family with status.
• Source: main/docs/features.md, main/docs/features/bgp-protocol.md.
• Status: existing.

reference/comparison.md

• Purpose: Ze vs FRR, BIRD, GoBGP, OpenBGPd, ExaBGP. Honest table, not marketing.
• Source: main/docs/comparison.md.
• Status: existing.

reference/configuration-reference.md

• Purpose: Every YANG node, type, default, validation rule. Generated from the schemas if possible.
• Source: schemas under main/internal/component/config/ (and plugin schemas).
• Status: stub for v1, generate later.

reference/deprecated-options.md

• Purpose: Things that used to work and no longer do, with migration paths.
• Source: main/docs/deprecated-options.md.
• Status: existing.

reference/glossary.md

• Purpose: BGP, Ze, and ExaBGP terms one page.
• Source: write fresh.
• Status: new.

5. Phasing

Not every page needs to be written before the wiki is useful. The implementer should ship in two phases:

Phase 1 -- "wiki is publishable"

The minimum set that makes the wiki worth pointing people at. Everything else is a stub or missing.

• Home.md
• _Sidebar.md, _Footer.md
• about/index.md, about/what-is-ze.md, about/architecture.md, about/status.md
• first-steps/index.md and all five first-steps pages
• configuration/index.md, configuration/overview.md, configuration/bgp/index.md, configuration/bgp/peers.md
• operation/index.md, operation/show-commands.md, operation/monitoring.md, operation/upgrade-and-restart.md
• interfaces/index.md and all five interfaces pages
• plugins/index.md (with the table only, individual plugin pages are stubs)
• plugin-development/index.md, plugin-development/go-plugins.md
• chaos-testing/index.md
• blueprints/index.md (empty list)
• development/index.md, development/building.md, development/contributing.md
• reference/index.md, reference/command-reference.md, reference/comparison.md

Phase 2 -- "wiki is complete"

Everything else from section 4. Per-plugin pages, blueprints, the long-form architecture page.

6. Conventions

• No em dash characters in English prose. Use commas, colons, parentheses, or --.
• Write in second person ("you configure", not "the user configures") for guides.
• Write in third person for reference and architecture.
• Code blocks use triple-backtick fenced blocks with language hints.
• Filenames are lowercase with hyphens.
• Headings start at ## inside a page (the H1 is the page title, set by Codeberg from the filename).
• Cross-links use relative paths: [peers](../configuration/bgp/peers.md).
• Source pointer at the bottom of every page that was adapted from main/docs/: > Adapted from [main/docs/...].
• Status banners at the top of pages whose content describes pre-alpha behavior: > **Pre-Alpha.** This page describes behavior that may change.
• Images live under wiki/images/. Re-use the existing screenshots wherever possible. Do not generate new images for v1.
• No emoji unless Thomas asks for them.