Docs / Support

Report Stage 1 issues in a reproducible way

Use this page to classify what happened, prepare a clean reproduction, and route support questions or workflow friction without widening the product claim.

The best support reports are narrow, exact, and explicit about whether the issue happened in canon, golden, onboarding, or CI.

Issue classes

Classify the problem as narrowly as possible

Onboarding friction

Install, archive, or path confusion

Use this when tobi.exe is missing, shipped examples are not where expected, or checksum verification is unclear.

Docs mismatch

Published guidance does not match the released line

Use this when the public docs omit a practical step or describe the Stage 1 surface inaccurately.

Diagnostics clarity

The validator rejects input, but interpretation is unclear

Use this when the code, message, or span is present but hard to read or map to the current docs.

Unexpected reject

Input appears to fail contrary to the released surface

Use this when the shipped sample or previously stable accepted input rejects unexpectedly.

Fixture mismatch

golden result diverges from expectation

Use this when canonical output, hash, code, or span mismatches the fixture expectation.

Workflow friction

Local success does not translate cleanly into CI

Use this when checkout, download, checksum, path, or runner setup blocks GitHub workflow evaluation.

Reproduction checklist

What to include in every useful report

  • exact command run
  • exact input file or fixture path
  • whether shipped sample material or partner-owned material was used
  • exact output received
  • whether the issue happened in canon or golden
  • diagnostic code and span when present
  • expected behavior versus actual behavior
  • release tag, branch, or host details when relevant

Useful feedback

What high-quality Stage 1 feedback looks like

  • reproducible rather than paraphrased
  • narrow in scope rather than platform-wide
  • explicit about whether the issue is onboarding, diagnostics, mismatch, or workflow friction
  • grounded in exact output rather than interpretation alone
  • one issue class per report whenever possible
Accepted input

If canon produced the expected output shape, do not file that as a validator failure.

Deterministic reject

If the validator rejected input with a stable code and span, classify it as expected reject, unexpected reject, or diagnostics clarity.

Scope misunderstanding

If the request is really about runtime, backend, or API expectations, treat it as product-scope misunderstanding rather than a Stage 1 defect.

Customer routing

Need help, workflow fit, or access updates?

Public docs should get most operators to a clean first evaluation. When the next step is a support conversation, CI integration question, or broader product inquiry, route it directly to Organetic.