This repository has been archived on 2026-07-29. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
kitchen-md/.claude/tasks/0003-view-skeleton.md
alexion d1c1f330c5 feat: add kitchen view command and parser skeleton (task 0003)
Cut the first complete thread through both layers with the smallest set
of node types.

@kitchen-md/core gains a pure, total `parse` returning a
`DocumentAST` of `{ frontmatter, blocks, diagnostics }`, built from a
minimal remark pipeline (remark-parse + remark-frontmatter) with an
internal translation layer to core's own types. This slice models
frontmatter passthrough, HeadingBlock, ParagraphBlock, and TextNode;
remark's mdast does not surface in the public API.

@kitchen-md/bin gains the `view` subcommand (commander) that reads a
file, calls `parse`, and passes the AST to a pure `render` that returns
an ANSI-styled string via chalk (auto-suppressed off a TTY). Frontmatter
prints as raw YAML followed by a separator, headings styled distinctly
by level, paragraphs as prose. A missing argument prints usage and a
missing/unreadable file a human-readable error, both exiting 1.

Richer blocks/inline plus raw fallbacks are task 0004; malformed
frontmatter diagnostics and the basic.md smoke test are task 0007.
2026-07-26 07:24:32 -04:00

5.5 KiB
Raw Blame History

spec
spec
cli-view

What to build

The walking skeleton: a runnable kitchen view <file> that reads a Recipe File, parses it, and prints it styled in the terminal. This slice cuts the first complete thread through both layers with the smallest set of node types.

In @kitchen-md/core, stand up the parse function and the types module, modelling only what this slice renders: frontmatter passthrough, HeadingBlock, ParagraphBlock, and TextNode. Set up the minimal internal remark pipeline needed for these (parse + frontmatter), with the translation layer from remark's output to core's own types. parse is a pure, total function returning a DocumentAST of shape { frontmatter, blocks, diagnostics }.

In @kitchen-md/bin, implement the view subcommand with commander taking one required file-path argument. The entry point owns file I/O: it reads the file, calls parse, and passes the DocumentAST to a pure render(ast) function. render walks the AST and returns an ANSI-styled string using chalk, which auto-suppresses colour when stdout is not a TTY. Frontmatter prints as raw YAML followed by a visual separator, then the body: headings styled by level, paragraphs as prose with blank-line spacing.

The demoable outcome: kitchen view <recipe.md> shows metadata, headings, and prose; a missing file prints a human-readable error to stderr and exits non-zero.

Acceptance criteria

  • parse returns a DocumentAST { frontmatter, blocks, diagnostics }; frontmatter is a plain object (empty when absent), diagnostics empty in the normal case
  • Core types live in a dedicated types module and are re-exported from the package entry point alongside parse
  • Headings (levels 16) and paragraphs are modelled as HeadingBlock and ParagraphBlock, with paragraph content as an inline array of TextNode
  • Blocks are flat and in document order (a heading is a sibling of the following paragraph, not its parent)
  • remark types do not appear in core's public API
  • kitchen view <file> reads the file, calls parse, and prints the rendered output
  • render(ast) is pure (no I/O, no side effects) and returns an ANSI-styled string
  • Frontmatter renders as raw YAML before the body, followed by a visual separator
  • Headings render bold and distinct by level; paragraphs render prose followed by a blank line
  • chalk styling is suppressed automatically when stdout is not a TTY
  • A missing file path prints commander usage to stderr and exits 1; an unreadable/nonexistent file prints a human-readable error to stderr and exits 1
  • Renderer unit tests (ANSI stripped) cover frontmatter, the separator, headings, and paragraphs
  • Core unit tests cover frontmatter passthrough (arbitrary fields, empty, absent), headings at every level, and paragraphs with TextNode content

Implementation Notes

All acceptance criteria are met. The following decisions and scope boundaries are worth recording.

Scope boundaries carried by the slice

Only HeadingBlock, ParagraphBlock, and TextNode are modelled, as the slice specifies. The remark→core translation therefore skips any block that is not a heading or paragraph (lists, blockquotes, code, thematic breaks), and translateInline keeps only text nodes, dropping every other inline node type. The drop is by whole node, so emphasised or linked text is currently lost, not merely unstyled. This is within task 0003's stated scope; the lossless RawInline/RawBlock fallback and the typed EmphasisNode/StrongNode/LinkNode land in task 0004, which also makes the translation recurse into container children.

Malformed-frontmatter handling is out of scope here and owned by task 0007. This slice parses well-formed frontmatter and returns {} for the empty and absent cases; a genuinely malformed YAML block would currently throw from the YAML parser. The total-function guarantee for that case (returning {} plus an invalid-frontmatter diagnostic) arrives with 0007.

Types defined ahead of full use

Diagnostic, Point, and Position are defined in the types module because DocumentAST.diagnostics is typed Diagnostic[], even though only the empty case (diagnostics: []) is produced in this slice. This keeps the public shape stable; 0007 populates the channel.

Rendering decisions

Headings render distinct-by-level via chalk, tapering from bold at level 1 toward dim at level 6; a heading is followed by a single newline and a paragraph by a blank line, which is what visually separates them once ANSI is stripped. Per the cli-view spec, the specific colour and weight choices are visual decisions verified by inspection, not asserted in tests — the renderer tests assert ANSI-stripped text, spacing, and the presence/absence of styling, not particular colours. The frontmatter separator is a dimmed 40-character box-drawing rule.

Tests that are green on arrival

A few required-coverage tests document behaviour that the minimal implementation already satisfies and so pass without a preceding red (frontmatter empty/absent, flat document order, and the level-distinctness/suppression renderer test). They assert real observable behaviour against independent literals rather than restating the implementation.

Review follow-up applied

The runCli and stripAnsi test helpers were extracted into packages/bin/src/test-support.ts to remove duplication the review flagged across the bin test files. The scaffold's remaining test.todo placeholders (future block/inline types, annotations, the smoke test) are left intact for their owning tasks.