scratchboard

Detection finds the tickets, picks a preset, and proposes lanes and facets on its own, so the three jobs below are the parts that take judgement or code.

You write two files, scratchboard.json and scratchboard.parser.mjs, both at the repo root, and you ask the user before each. None of the three jobs changes a ticket.

Moving a card is the other job and it needs no config. A lane that matches on a field is moved by writing that field in the ticket, one line, in the vocabulary the repo already uses. The board never writes it, because the board is read-only.

The vocabulary a card is moved with

Read the repo's own values first, from its lanes in scratchboard.json and from the tickets themselves, and write what is already there. The list below is the vocabulary the skills speak in, which is what a repo that has none of its own should use.

The first five are the canonical triage roles. done is scratchboard's own terminal state, because the five are a triage queue rather than a lifecycle. A repo may carry values outside both sets, as this one carries deferred for work someone looked at and chose later. Those pass through untouched, take their lane from local config, and are never rewritten into a value from the table.

The reader spec is docs/local-markdown-spec.md in the scratchboard repository. It names every value the board recognizes, the file shapes it reads, and what happens to input it does not recognize. Read it rather than guessing, and do not restate it in a repo's own docs.

1. Locate the tickets