Developer support should start with repo ownership, not with a generic inbox. The fastest useful answer usually comes from choosing the right repository, running the local verification path for that repo, and attaching a minimal reproducible bundle.
Pick The Owning Repo First
| Surface | Owning public repo | Typical local verification |
|---|---|---|
| Rust crates, rollup node, wallets, simulator, runtime, workspace tooling | z00z-labs/z00z |
cargo check --workspace, cargo test --workspace, ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh |
Docs site, Next.js routes, Markdown content, _meta.yaml, search coverage, rendering |
z00z-labs/z00z-website |
npm run lint, npm run verify |
If you start in the wrong repo, the maintainer first has to re-route the issue before debugging it.
Start With The Deepest Local Source
Before opening a support request, check the page that matches your question:
| Question type | Best first page |
|---|---|
| Website setup and command flow | Get Started |
| Docs-site verification expectations | Verification And Tests |
| Repo layout and where work belongs | Rust Workspace |
| AI-assisted workflow rules | AI Agent Playbook |
| Security wording and disclosure boundaries | /docs/security |
If the source page already answers the question, support has already worked.
What To Collect Before Asking For Help
Collect the smallest bundle that lets someone reproduce the issue:
- the owning repo;
- the exact command you ran;
- the exact file, route, crate, or binary involved;
- the short error excerpt or unexpected result;
- whether the failure is in
cargo,npm, build, lint, tests, or verification; - whether the issue is ordinary public debugging or security-sensitive.
That is enough for most builder questions. More text is not automatically more useful.
Public Versus Private Routing
Use public repo workflows for ordinary, non-sensitive problems. Use the security path instead when the request includes:
- exploit details;
- privacy leakage;
- secret handling;
- trusted-channel impersonation;
- anything that becomes more dangerous if copied into a public thread.
Technical users are often the most likely to over-share. Public support must prevent that.
Builder Routing Table
| Question type | Best route |
|---|---|
cargo failure in the Rust workspace |
z00z-labs/z00z |
npm failure, Next.js render break, content route issue, or search-coverage regression |
z00z-labs/z00z-website |
| Claim mismatch between docs, whitepapers, and code | start with the repo that owns the visible defect and include source citations |
| Security-sensitive issue in either repo | Responsible Disclosure |
Developer Support Routing Flow
If a claim mismatch is visible on the website, start in z00z-website and link the whitepaper or code source that appears to disagree. If the mismatch is visible in the Rust workspace or its docs corpus, start in z00z.
What Maintainers Need Most
From a maintainer’s perspective, the best support request separates:
| Helpful signal | Why it matters |
|---|---|
| Exact command | Reproduction starts from the same entry point |
| Exact path, crate, or route | Confirms the owning surface |
| Expected versus observed behavior | Prevents guesswork |
| Security sensitivity flag | Decides public versus private routing |
| Source anchor | Shows whether the claim is repo-local, corpus-backed, or speculative |
Without that structure, support turns into archaeology.
Verification Failure Triage
Verification failures should be named by the failing step, not by vague labels:
| Failure lane | What to report |
|---|---|
cargo check, cargo test, or full Rust gate |
exact crate/binary, command, and failing excerpt |
npm run lint |
file path, lint rule, and changed files |
npm run verify |
whether lint, search coverage, or production build failed |
Do not summarize everything as “the build is broken” when the failing lane is known.
Cross-Repo Claim Mismatches
Many developer questions are really claim-ownership questions. Documentation may sound stronger than the code currently proves. A Rust crate may expose a narrower surface than a website summary suggests. A wallet or runtime route may describe architecture that is corpus-backed but not yet fully shipped in the local implementation.
When that happens, the support request should include both the visible claim and the source that appears to disagree with it. For example: the page path in z00z-website, the crate or command in z00z, the relevant whitepaper section, and the exact sentence that appears too broad. That package lets maintainers decide whether the fix belongs in docs wording, code, tests, or all three.
What A Good Escalation Package Looks Like
The best escalation package is still small:
| Field | Why it helps |
|---|---|
| owning repo | avoids immediate re-routing |
| command or route | anchors reproduction |
| failing file, crate, or page | narrows the surface quickly |
| source citation when the issue is conceptual | keeps the answer evidence-bound |
| sensitivity flag | decides public versus private handling |
This is the difference between a support question and a supportable question.
Public Thread Hygiene
Public developer threads should stay scoped. Post the failing command, the short error excerpt, the route or crate, and the expected behavior. Do not paste private logs, full local histories, wallet secrets, or broad screenshots that reveal more than the bug requires. A narrower repro is usually easier to review and safer to archive.
When a thread starts drifting into architecture debate, move it back to source ownership: which repo, which file, which command, which citation.
If the answer still depends on memory instead of a local source, the thread is not ready for confident resolution.
What Developer Support Cannot Own
Developer support should not pretend to own:
- user wallet recovery;
- staffed end-user custody support;
- third-party issuer, bridge, or hosted-service operations;
- unpublished APIs, commands, or guarantees.
If the evidence is missing, the safest answer is to say which source is missing and route the question to the correct surface.
Support Boundaries
Developer support optimizes for reproducibility, source ownership, and safe escalation. It does not duplicate the full developer documentation, invent interfaces, or widen public trust claims beyond what the repositories prove. Each escalation identifies the affected repository, exact command or route, and whether the evidence belongs in a public or private channel.
Public support avoids internal process jargon. It names the real failing command or verification step, not an unpublished internal workflow label.
Final Boundary
Developer support should keep implementation, content, and security questions separate. An implementation issue needs the owning repo. A content issue needs the route and file. A security issue needs the private path.
Precise routing is part of developer safety.
Read Next
Read Troubleshooting for website-repo command triage, Source Authority Map for claim ownership, and Responsible Disclosure for sensitive developer findings.
Evidence and Further Reading
github.com/z00z-labs/z00zis the public main project repository for the Rust workspace, runtime, wallets, and simulator surfaces referenced here.github.com/z00z-labs/z00z-website,README.md,package.json, andscripts/verify.shdefine the public docs-site verification path referenced here.content/docs/developers/*, includingget-started.md,verification-tests.md, andai-agent-playbook.md, document the self-service builder flows available to technical users.- Main Whitepaper section 12 and sections 10 and Appendix C explain why docs and developer support must distinguish repo-local proof from broader protocol or service claims.
- Legal Architecture sections 4, 9, 17, and Appendix A define the safe public-claim and interface-boundary rules 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.