This repository is a working documentation and website product. It is not, by itself, the complete Z00Z protocol implementation. A productive first session therefore has two tracks: use local commands and paths for anything about the website, and use the whitepaper corpus for anything about protocol architecture that is not implemented in this tree.

The practical goal is simple. By the end of the session you should be able to install dependencies, run the site, edit a docs page, understand where the route comes from, run the verification gate, and review whether a new claim is locally evidenced or only corpus-backed target architecture.

First Session Checklist

Start at the repository root. The commands below are the ones exposed by package.json; do not substitute a broader product CLI or a guessed protocol daemon.

npm install
npm run dev
npm run lint
npm run verify

npm run dev runs the Next.js development server through the repository’s default webpack dev path. npm run dev:turbo also exists, but it is a separate script, not the default first-session path. npm run verify is the completion gate you should learn early because scripts/verify.sh runs the same three-part bundle every contributor should respect: lint, search coverage, and production build.

Edit The Right Surface

Most first contributions should start in content/docs/. A page’s body, frontmatter, Mermaid diagrams, evidence links, and reader path live there. Navigation order usually lives in a nearby _meta.yaml. The renderer that turns Markdown into HTML lives in src/lib/content/markdown.ts. The loader that resolves frontmatter, landing cards, TOC items, and domain pages lives in src/lib/content/docs.ts.

That split prevents two common mistakes. First, do not change React route code just to fix page wording. Second, do not change a docs page to make a renderer claim unless the renderer actually supports the pattern. If you use alerts, tabs, Mermaid, or TOC behavior, verify that the existing Markdown pipeline supports the feature and then render it locally.

The current section indexes also have a hard local rule: every content/**/index.md file is route metadata only and must contain YAML frontmatter with no body content. If you want to add explanatory prose for a section, put it in a non-index page.

Understand Routes Before Editing

The public docs route is not hand-written page by page. The docs content tree is loaded by the existing content system and rendered by the Next.js App Router. In practice, that means:

When a page fails to appear, check the file path, frontmatter, _meta.yaml, and build output before assuming the route layer needs new code. The current repository already has the generic docs route; most Phase 002 work extends content and verification, not route architecture.

Edit-To-Verify Flow

The safest first-session loop is short enough to memorize:

The evidence step is not optional. If the claim is about a repo command, use package.json, scripts/, or source code. If the claim is about protocol objects, settlement, wallet-local possession, post-quantum posture, privacy, legal language, or roadmap status, use content/whitepapers/ and cite the relevant paper in the page’s evidence section.

What Verification Covers

npm run verify is a real local gate, but it is not a magical proof of every documentation requirement. It runs lint, search coverage, and production build. Search coverage checks that indexed content is discoverable; build proves that Next.js can compile and render the app. Those are necessary, not sufficient.

For Phase 002 docs work, you also need page-local checks:

If a page passes npm run verify but still says that this website repo ships a complete wallet SDK, rollup node, or core protocol API, the page is still wrong. Build correctness is not claim correctness.

Manual Review Before Closeout

Before you summarize a change, do one manual pass that the scripts cannot fully replace. Open the rendered page, check that the title and description match the intended route, confirm that Mermaid diagrams render, and click the Read Next links. Then scan every present-tense implementation sentence. If it names a local command, file, route, loader, or script, the evidence should be in this repository. If it names protocol execution, wallet behavior, cryptography, disclosure, governance, or post-quantum posture, the evidence should be in the whitepaper corpus and the wording should say whether the claim is live, target, or conceptual.

This review is especially useful for developer pages because they sit between two worlds. They must help builders act locally, but they also introduce protocol concepts that are not all shipped from this website tree. The page is complete only when both sides are readable.

Common First-Session Mistakes

The fastest way to create drift is to import assumptions from a different kind of repository. Avoid these patterns:

A Good First Change

A good first change is narrow but evidence-rich. For example, improve one developer page so it cites package.json, scripts/verify.sh, and the right whitepaper sections. Add a Mermaid diagram only if it clarifies a real flow. Update _meta.yaml only when route order actually needs to change. Keep the summary factual: what changed, what verified, and which warnings remain.

If an AI assistant is involved, route it through the same discipline. It should read the plan, inspect the target files, keep artifacts in English, avoid destructive operations, run the local verification path, and separate local implementation claims from corpus architecture. Automation is useful here only when it strengthens evidence.

Read Next

Continue to Workspace to understand where files belong, then read AI Agent Playbook if an assistant will help with the change. Open Core Protocol API when you are ready to connect repo work to the protocol object model.

Evidence and Further Reading

• package.json defines the local scripts used on this page: dev, dev:turbo, lint, verify:search, and verify.
• scripts/verify.sh defines the canonical repository verification bundle: lint, search coverage, and production build.
• Workspace explains the repository shape and where content, routes, configuration, scripts, planning, and instructions live.
• Main Whitepaper section 12 distinguishes what is already live from target architecture and proposed expansion work.