Developer support should start with self-service because the best technical question is the one that arrives with reproducible evidence already attached. In this repository, the first stop for most builder problems is not a human inbox. It is the local docs, the whitepaper corpus, and the repo verification flow that already define what can be proven here.

Start With The Deepest Local Source

Before escalating, check the page that matches your question:

If those pages answer the question, support has already worked and no extra escalation is needed.

What To Collect Before Asking For Help

When the docs still leave a gap, collect a minimal reproducible bundle:

• the exact file or route involved;
• the command you ran;
• the exact error or unexpected output;
• whether npm run lint fails, npm run verify fails, or both;
• the smallest set of changed files that reproduces the issue;
• whether the issue is purely docs-site behavior or a corpus/claim-discipline problem.

That bundle is usually enough for a docs repo. It also keeps the question narrow enough that a maintainer or reviewer can reproduce it without guesswork.

Public Versus Private Routing

Use the public repo workflow for ordinary docs, build, navigation, or wording issues. Use the security path instead when the question includes:

• exploit details;
• secret handling;
• privacy leakage;
• trusted-channel impersonation;
• anything that becomes more dangerous if copied into a public thread.

This boundary is especially important for developers because technical users are often the most likely to over-share detailed reproduction data before asking whether the data is safe to publish.

What Maintainers Need Most

From a maintainer’s perspective, the best support request is one that separates:

Without that structure, the support path turns into archaeology.

What This Repo Can Support Best

This repository is strongest at helping with:

• docs rewrites and navigation problems;
• search or verification regressions;
• maturity and wording drift;
• contributor workflow confusion;
• evidence mismatches between content/docs/ and content/whitepapers/.

It is weaker as direct proof for full runtime, operator, or hosted-service behavior outside the tree. Good developer support should say so instead of pretending every concept described in the corpus is already present as a local executable surface.

When To Use The Repo Tracker

For ordinary builder problems in this repo, use the public issue or pull-request workflow attached to github.com/z00z-labs/z00z-website. Keep the report concrete and local. If the issue is really a security problem, do not post the exploit details publicly just because the repo tracker is the most visible route.

Developer Support Routing Flow

The routing flow keeps developer support from becoming a dumping ground. Setup questions need commands and environment details. Content questions need path, route, frontmatter, and _meta.yaml context. Concept questions need the relevant whitepaper and docs links. Verification failures need the exact failing command and phase. Security-sensitive details belong outside ordinary support, even when the reporter is a developer.

What This Repo Cannot Own

This repository is weaker at answering product-support questions for wallets, issuers, bridges, hosted services, or external operators. Those surfaces may depend on future repositories or third-party systems. Keep questions scoped to this website repo unless the source evidence explicitly points elsewhere. A developer-support answer should not invent an API, command, or operational guarantee just to satisfy a broad question.

Claim Source Questions

Many developer questions are actually source-authority questions. If a page describes a feature as current, ask which repo file or test proves it. If a page describes architecture, ask which whitepaper owns it. If a page describes support or legal posture, ask which legal or security page constrains it. That triage prevents developer support from inventing answers that should be source-bound.

Setup And Rendering Issues

Setup issues should start with npm ci, then the specific command that failed. Rendering issues should identify whether the problem is Markdown, frontmatter, Mermaid, navigation metadata, or the runtime shell. Content source checks should identify the whitepaper citation or repo file that owns the claim. API concept questions should be routed to developer docs and the relevant whitepaper, not answered from memory when the source exists locally.

Verification Failure Triage

Verification failures need the phase name. Lint failures are different from search-coverage failures, and both are different from production build failures. A developer-support request should say which step failed and provide the smallest output excerpt that identifies the problem. If a failure involves secrets, exploit steps, or private logs, stop and route it to responsible disclosure. If it is a normal docs failure, public support is usually appropriate.

Avoid Duplicating Developer Docs

Developer support should route, not duplicate. If a page already explains wallets, RPC, API concepts, examples, or verification tests, link to it. Duplicating those docs in support creates drift and makes later updates harder. A support page should explain where to go, what evidence to collect, and which boundary applies.

Review Notes

Developer-support pages should optimize for reproducibility. A maintainer needs the command, path, route, expected behavior, observed behavior, and security sensitivity. A broad narrative without those fields costs more time than it saves. The page should train contributors to provide the smallest useful bundle.

Support should also refuse concept drift. If a developer asks for an API that does not exist, the answer should route to the relevant conceptual docs or source file rather than inventing a convenient interface. If a developer asks whether a claim is live, the answer should require repo evidence. If a developer asks a whitepaper question, the answer should cite the paper and section.

Final Boundary

Developer support should keep implementation, content, and concept questions separate. An implementation answer needs a repo anchor. A content answer needs a file and route. A concept answer needs the owning whitepaper. Mixing those answer types is how support pages drift into parallel architecture.

If a question cannot be answered from local files, the safest support response is to say which evidence is missing and route the question to the relevant owner or future work item instead of improvising a new interface or command.

Precise routing is part of developer safety.

It keeps support answers reproducible, source-bound, and easier to review.

Read Next

Read Troubleshooting for commands, Source Authority Map for claim ownership, and Responsible Disclosure for sensitive developer findings.

Evidence and Further Reading

• content/docs/developers/*, including get-started.md, verification-tests.md, and ai-agent-playbook.md, document the main self-service builder flows referenced here.
• README.md, package.json, and scripts/verify.sh define the reproducible local command path that developer support requests should use.
• Main Whitepaper section 12 and sections 10 and Appendix C explain why docs support must distinguish repo-local proof from broader protocol or service claims.
• Legal Architecture Whitepaper sections 4, 9, 17, and Appendix A define the safe public-claim and interface-boundary rules that developer support should preserve.
• Privacy Threat Model And Metrics sections 7, 9, and 10 are the source anchors for careful handling of secrets, exploit details, telemetry, and disclosure scope in public developer reports.