bazable review

Audit provenance and inference confidence for every endpoint in your contract.

Renders a human-readable audit of your contract so you can see exactly where each endpoint came from and how confident Bazable is about every inferred field. Use it to review assumptions before pushing to teammates or CI.

Usage

bazable review [options]

Options

--filter · string

Filter endpoints by URL substring or regex (case-insensitive). Falls back to substring match if the pattern is not a valid regex.

--json · boolean

Output the report as JSON. Useful for piping into other tools or CI checks.

What it shows

For every endpoint in bazable.config.json, bazable review prints:

• Sources — file, line, and column of every call site that referenced the URL (provenance).
• Request schema — each field with its inferred type, confidence level, and the original source value when available.
• Response schema — fields and types (when captured).

Fields flagged low or medium confidence are marked ⚠️ needs confirmation so you can review them before trusting them in production.

Confidence levels

Confidence	Meaning
high	Value was a literal (string, number, boolean, null) in the source.
medium	Value came from an identifier (variable) or object expression. Type is a best guess.
low	Value shape could not be resolved from the AST.

Example output

🔍 Bazable Contract Review

POST https://api.example.com/v1/users
  📁 Sources:
    - src/pages/signup.tsx:42:18
    - src/pages/admin/invite.tsx:88:12
  📥 Request schema:
    - email: string [confidence: high] (source: "[e-mail]")
    - name: string [confidence: medium] ⚠️ needs confirmation
    - age: number [confidence: high] (source: 30)
  📤 Response schema:
    - id: string
    - createdAt: string

Filtering and JSON output

Filter by substring

bazable review --filter users

The JSON shape mirrors what is stored in bazable.config.json:

{
  "POST https://api.example.com/v1/users": {
    "provenance": [
      { "file": "src/pages/signup.tsx", "line": 42, "column": 18 }
    ],
    "request": { "email": "string", "name": "string" },
    "request_meta": {
      "email": { "inferred": true, "confidence": "high", "source_value": "[e-mail]", "source_type": "StringLiteral" },
      "name":  { "inferred": true, "confidence": "medium", "source_value": null, "source_type": "Identifier" }
    },
    "response": { "id": "string", "createdAt": "string" }
  }
}

When to use it

Before pushing

Audit inferred schemas before running bazable push so teammates don’t inherit unverified guesses.

After extraction

Run right after bazable extract --payloads to see which fields Bazable is unsure about.

Code review

Include the review output in PRs when you add new endpoints so reviewers can verify assumptions.

Debugging drift

Trace a failing bazable inspect or bazable test back to the exact call site that introduced the endpoint.

Provenance and request_meta are written by bazable extract. Re-run extraction after any code changes to keep the review accurate.

The metadata is stored alongside the existing simple schema format in bazable.config.json (endpoints[url].provenance and endpoints[url].request_meta). Older tooling that only reads request and response continues to work unchanged.