Wiki Maintenance

This page defines how to keep the internal wiki useful.

The wiki is not a scrapbook. It is the team's navigable memory and operational manual.

Update Triggers

Update the wiki when any of these happen:

Trigger	Pages to check
Protocol interface changes	Deployment runbook, repo contracts, verification matrix, protocol repo page
SDK public API changes	SDK repo page, release management, docs references
New repo is added	Workspace map, repo contracts, README, VitePress sidebar
Deployment process changes	Protocol deployment runbook, environment registry, verification matrix
New environment/domain/service	Environment registry, infra page, repo page
Incident occurs	Incident response, relevant runbook, post-incident notes
Milestone ships	Planning status, milestones, home page current state
Architecture decision changes	Architecture page and ADR
Public docs change materially	Docs repo page and relevant internal source page

What Belongs Here

Put these in the wiki:

• durable operating rules
• runbooks
• architecture summaries
• repo ownership and contracts
• environment constants without secrets
• release and verification commands
• incident response procedures
• rationale for major decisions
• links to current source artifacts

Do not put these in the wiki:

• raw secrets
• private keys
• temporary scratch notes
• unverified guesses
• raw command output dumps unless they prove a runbook
• stale TODO lists that belong in .planning/todos
• public marketing copy that belongs in vela-web
• public developer docs that belong in vela-docs

Conflict Resolution

When docs disagree:

1. Check live code and deployed state.
2. Check vela-protocol IDL/program IDs for protocol interface truth.
3. Check vela-sdk for consumer-facing TypeScript truth.
4. Check .planning/PROJECT.md and STATE.md for current intent.
5. Update the wiki page that is stale.
6. If public docs are stale, update vela-docs after the internal source is correct.

Page Quality Bar

A good internal wiki page has:

• a clear owner or owning repo
• commands that can be copied
• warnings where mistakes are expensive
• current paths and program IDs
• explicit assumptions
• links to adjacent pages
• no unexplained historical leftovers

Review Checklist

Before considering a wiki update done:

• [ ] The page builds with VitePress.
• [ ] Links use existing pages.
• [ ] Commands use current repo paths.
• [ ] Package names match current package manifests.
• [ ] Program IDs match the environment registry.
• [ ] No secrets are included.
• [ ] Any warnings are concrete and actionable.
• [ ] README/sidebar/home page links are updated if a new page was added.

Build

cd /Users/laitsky/Developments/vela-labs/internal-wiki

bun run build

The build must pass before the wiki can be treated as current.