Vocabularies and shared types
The enumerated values and structured shapes tool arguments are drawn from. Each vocabulary has a single definition that every Binclusive surface shares, so a value accepted here means the same thing in the dashboard, the CLI, and an exported report.
Impact
Section titled “Impact”The accessibility impact scale, ordered most to least severe. Used by create_ticket.
critical · serious · moderate · minor · unknown
unknown is the explicit “not yet judged” bucket, not a missing value.
Ticket status
Section titled “Ticket status”A ticket’s workflow status. Used by list_agentic_tickets (filter) and
update_agentic_ticket_status.
BACKLOG · TODO · IN_PROGRESS · DONE · WONT_FIX
Status is server-assigned and cannot be set at creation time — create_ticket takes no status.
Priority
Section titled “Priority”Used by list_agentic_tickets as a filter.
P0 · P1 · P2 · P3
Also server-assigned; not settable through this server.
Platform
Section titled “Platform”The surface a finding lives on. Used by list_agentic_tickets as a filter.
web · ios · android · unity · unknown
Project type
Section titled “Project type”The platform a project audits. Used by create_project, default web.
web · ios · android
A narrower list than Platform above: unity and unknown describe where a finding was
observed, not the platforms you can create a project for.
Project use cases
Section titled “Project use cases”What you want from a project. Used by create_project, at least one required, default
["usability"].
| Wire value | Meaning |
|---|---|
usability | Outcome-based journey audits. |
ci | Gating builds on findings. |
altText | Image and icon descriptions. |
Locations
Section titled “Locations”create_ticket’s location is one of two shapes, discriminated by kind.
Page location
Section titled “Page location”{ "kind": "page", "url": "https://example.com/checkout" }| Field | Type | Required | Notes |
|---|---|---|---|
kind | "page" | yes | |
url | string | yes | The page URL the occurrence was observed on. Non-empty. |
url is page metadata, never a source file:line locator.
Source location
Section titled “Source location”{ "kind": "source", "path": "src/Pay.tsx", "lineHash": "9f2c…", "index": 0, "line": 42 }| Field | Type | Required | Notes |
|---|---|---|---|
kind | "source" | yes | |
path | string | yes | Repo-relative filename. Non-empty. |
lineHash | string | yes | One-way hash of the whitespace-normalized offending line. |
index | integer ≥ 0 | yes | Disambiguates identical line content within one file. |
line | integer > 0 | no | 1-based line number, display only. |
Your source code never leaves your machine. lineHash is a one-way fingerprint of the offending
line, not the line itself, and it cannot be reversed. It is what lets the same finding be recognised
after the code moves. line is there so a ticket has somewhere to link; it may go stale as the file
changes, and nothing depends on it.
Compute lineHash as the MD5 of the offending line with every space and tab removed, as a hex
digest. Stripping the whitespace is what stops a re-indent or a reformat from looking like a new
finding:
crypto.createHash("md5").update(line.replace(/[ \t]/g, "")).digest("hex")Use exactly this. A different hash is a different fingerprint, so the same defect filed twice with two recipes becomes two tickets rather than one.
Both shapes reject fields they do not recognise, so a payload carrying a snippet or source field
is refused rather than quietly stored.