Documentation

The lines okf computations prints, as data. Pure and separate from runComputations so a test can assert the whole report rather than only the accessors behind it; renderProfileDetail is exported for the same reason.

Concepts arrive in walkBundle order and keep it. Column widths are computed over the selected rows only, so one unrelated long concept ID elsewhere in the bundle cannot pad this report.

The lines okf concepts prints, as data: concept ID, type, one column per requested key, and title last. Pure and separate from runConcepts so a test can assert the whole report rather than only the accessors behind it, as computationReport and renderProfileDetail already are.

The three default columns are the ones conceptCandidates shows in the interactive concept picker, so the two listings agree.

title comes last and is never padded, so a long title cannot push anything off the right edge and a concept with no title simply ends the line. Column widths are computed over the rows actually printed, so one unrelated long concept ID elsewhere in the bundle cannot pad a filtered listing.

The rows okf concepts --json emits.

title is null when the concept has none, and fields is present even when no key was requested, so a consumer never has to test for it. The values under fields are the raw frontmatter values rather than the display text a column shows: a JSON consumer wants a list back as a list.

Environment override for the registry okf profile reads.

One profile's complete rule set. Every optional field prints as (none) rather than being omitted, so the output shape does not change between profiles and stays reliable to eyeball or grep. Type rules print in the order the profile declares them, since that order is the author's.

One deviation as one line. The ProfileSpec is here only so a missing required field can carry the profile's own explanation of what that field is for; every other case ignores it.

Exported so a test can assert a whole diagnostic line rather than only the accessors behind it, as computationReport and renderProfileDetail already are. The constructors that quote a frontmatter value back to the author ignore both the CompiledProfile and the concept list, so such a test can pass any compiled profile and an empty list.

An aligned table: a header row plus one row per profile, columns padded to their widest value. Pure so it can be tested without evaluating any Dhall.

DESCRIPTION comes last so the existing columns keep their positions and a long description cannot push anything off the right edge. Nothing follows it, so it is never padded; an absent description reads -, matching ID FIELD.