gatelineAPI reference
interface WorkItem {
    acceptanceTests: string[];
    dependsOn: string[];
    fileContactSurface: string[];
    id: string;
    notes: string;
    path: string;
    requirements: string[];
    scope: string;
    status:
        | null
        | "done"
        | "pending"
        | "in-progress"
        | "in-review"
        | "review-approved"
        | "verified";
    statusText: string;
    title: string;
    withheld: null
    | string;
}

Properties

acceptanceTests: string[]
dependsOn: string[]

Ids of items that must merge first, verbatim.

fileContactSurface: string[]

The declared file_contact_surface, verbatim and in declared order. Entries are whatever the architect wrote — repo-relative paths in practice, but the record also carries prose entries, and neither is normalized here.

id: string

The id: value — what depends_on elsewhere in the set refers to.

notes: string
path: string

Run-relative path, e.g. 'tasks/01-pr-ensure.yaml'.

requirements: string[]

Spec requirement ids this task covers, verbatim and in declared order.

scope: string
status:
    | null
    | "done"
    | "pending"
    | "in-progress"
    | "in-review"
    | "review-approved"
    | "verified"

Null when the status cell is not a word the contract names.

statusText: string

The status cell verbatim — the record's word, not this parser's.

title: string
withheld: null | string

Why a structured view of this item must withhold itself, or null when it applies. Contracts are forkable, so a task file may legitimately follow a grammar this parser does not know; the contracts' own bounce rule turned on the UI is to say so and fall back to the raw file, never to guess. The other fields still carry whatever did parse — a withheld item is not an empty one, it is one no derived view may speak for.