Docs / GitHub Actions

Run Tobi Validator through the public GitHub Action wrapper

The current public launch path starts with the public OrganeticSphere/tobi-validator repository. That repo is the public docs, examples, and action-wrapper surface for the released validator line.

The wrapper is consumed as uses: OrganeticSphere/tobi-validator@v1. Real execution remains controlled and uses the repository secret TOBI_EVAL_TOKEN in the current public evaluation path, so this page does not describe unrestricted public binary download.

Use this page when

  • you want the public repo and wrapper path, not a manual bundle flow
  • your workflow repository can store TOBI_EVAL_TOKEN
  • you want canon and golden checks as a narrow GitHub gate
GitHub-first only. The public repo is the entry surface. Controlled binary access stays separate from that surface.
What this is

A public repo plus action-wrapper path for placing the released validator CLI inside a narrow GitHub workflow gate.

What remains controlled

Binary delivery and execution stay controlled. Workflow runs in the public evaluation path require TOBI_EVAL_TOKEN.

What it is not

Not unrestricted public binary download, not a hosted service, and not a verification API or broader platform launch.

Before you add CI

Set up the wrapper path cleanly

  1. Start from the public repo Use OrganeticSphere/tobi-validator as the public source for docs, examples, and wrapper usage.
  2. Request evaluation access first Go to /eval-access.html, request a 7-day token, and keep that token ready before editing the workflow.
  3. Configure the workflow secret Add TOBI_EVAL_TOKEN to the consuming repository and store the value returned by the evaluation access page.
  4. Use the bundle-accurate sample paths first Start with examples/sample.tsubasa and examples/golden/fixtures.json before switching to repository-owned inputs.
  5. Pin the released version explicitly Keep stage1-tobi-validator-v0.7.0 explicit in the wrapper inputs so the workflow reflects the released Stage 1 line.

Common first uses

Start with one of these narrow goals

PR gate

Protect a repository from invalid reasoning artifacts

Use the workflow to block merges when validator checks fail or fixtures diverge from current expected behavior.

Release gate

Require stable conformance before publication

Use the same narrow validator path before tagging or publishing workflow changes.

Evaluation path

Decide whether the workflow fit is operationally useful

Keep the first experiment simple and reproducible before asking for broader integration conversations.

Runner compatibility note

Start with the documented runner path

The public Stage 1 workflow path should follow the runner configuration shown in this guide. If your team needs another runner, treat that as an evaluation/support question rather than assuming unrestricted platform support.

This page documents the current public workflow fit. It does not imply a broad runtime, backend, or platform maturity claim.

Representative YAML

Minimal GitHub Actions consumer example

Keep the first version plain and release-accurate. The public repo is the wrapper surface; the secret-backed action run is the controlled execution path.

name: Tobi Validator Consumer Test

on:
  workflow_dispatch:
  pull_request:

jobs:
  canon:
    runs-on: windows-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Run Tobi Validator action in canon mode
        uses: OrganeticSphere/tobi-validator@v1
        with:
          eval_token: ${{ secrets.TOBI_EVAL_TOKEN }}
          version: stage1-tobi-validator-v0.7.0
          mode: canon
          canon_input: examples/sample.tsubasa

  golden:
    runs-on: windows-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Run Tobi Validator action in golden mode
        uses: OrganeticSphere/tobi-validator@v1
        with:
          eval_token: ${{ secrets.TOBI_EVAL_TOKEN }}
          version: stage1-tobi-validator-v0.7.0
          mode: golden
          golden_fixtures: examples/golden/fixtures.json

Pass posture

What success should look like

The jobs complete only when the wrapper resolves correctly, TOBI_EVAL_TOKEN is present, and the validator accepts the chosen canon and golden inputs.

Failure posture

What should fail the workflow

Missing secret, missing files, deterministic reject, and golden mismatch should all block the workflow until understood.

Scope discipline

What not to read into this page

A public wrapper repo plus controlled binary access does not turn the product into unrestricted binary distribution, a broader platform, backend, or verification API surface.

Common first mistakes

Check these before escalating

  • the workflow never received TOBI_EVAL_TOKEN
  • the token was not requested first at /eval-access.html
  • the wrapper was not called as OrganeticSphere/tobi-validator@v1
  • the workflow uses the wrong sample or fixtures path
  • the pinned version does not match the released Stage 1 line
  • the failure is an operator/setup issue, not a product-scope signal
  • a golden mismatch was misread as a broad platform failure

Workflow fit

Ready to validate GitHub workflow fit or report wrapper friction?

Use the public repo and the action wrapper first. Then decide whether the value is in canonical discipline, conformance checks, or a narrower workflow-fit discussion.