Wavemap Docs

This site is the curated entry point for learning Wavemap’s product model, codebase, infrastructure, delivery controls, and operating procedures. Working notes retain active plans and exact proof history; pages here explain the current system clearly enough for engineers to navigate into its owning source.

The goal is not to publish every note in the repository. Instead, we seek to keep a stable admin, developer, and operations guidance in focused pages while active planning and proof history stay in working notes.

Choose A Path

Learn The Platform

Start with Platform Orientation to understand how source, CI, product-owned Pulumi, the Tendril state foundation, AWS, manual delivery, disposable Development data, and evidence fit together.

Continue through:

1. Monorepo Map for application, package, CLI, operations, infrastructure, and docs ownership.
2. Testing Runtime And CI for exact-source repository assurance.
3. Deployment Workflows for application-only, operator, docs, and infrastructure paths.
4. Data Durability And Recovery for the disposable Development boundary.

Change The Codebase

Developer is for engineers changing applications, packages, tests, infrastructure source, tooling, and the docs site.

Operate Development

Operations / Platform leads to the current environment model, manual delivery procedures, infrastructure-change policy, and reviewed runbooks. Plans and CI establish eligibility; they do not grant live authority.

Understand Content

Admin / Content begins with the current content model without presenting the future CMS as complete.

Main Sections

• Admin / Content is for individuals managing Wavemap content concepts and future CMS workflows.
• Developer is for those changing the platform, applications, packages, and docs site.
• Operations / Platform is for those deploying, debugging, recovering, or maintaining the hosting environments that support the system.

Developers will often read all three sections. Admin docs should remain usable without deep platform knowledge, and operations docs should keep approval gates visible instead of hiding them behind quick commands.

Current Scope

• Provide a stable information architecture around admin, developer, and operations reader jobs.
• Publish durable summaries, references, runbooks, and reviewed generated assets when their boundaries have settled.
• Keep raw working notes, proof evidence, cloud inventories, and private operational artifacts out of the public docs site.
• Keep versioned docs, preview docs, generated API documentation, and private-docs access control deferred until audience need justifies the machinery.

Documentation Contract

Curated pages should answer four questions:

1. What is the current mental model?
2. Which repository area owns the implementation?
3. Which authority and safety boundaries apply?
4. Which source and tests should a maintainer read next?

Exact live values still come from reviewed source, plans, provider readback, and protected receipts. Documentation is a map into those authorities, not a parallel configuration store.