Feature request: OKF bundle viewer (static render + local live server)

[jchable]

Motivation

Today, exploring an OKF bundle means reading raw markdown files or using okf graph --dot | dot -Tsvg for the link graph. There's no way to browse a bundle interactively: see concept frontmatter, follow links between concepts, or search full-text without piping through the CLI verbs one at a time. A viewer would make bundles approachable to people who aren't already comfortable with the CLI — useful for onboarding, demos, and day-to-day authoring.

What it should do

• Static rendering: generate a browsable HTML site from a bundle — one page per concept (frontmatter + rendered markdown body), an index page (reusing OKF4net.IndexGenerator), inter-concept links rewired to the generated pages, and client-side full-text search over an index derived from ConceptSearch.
• Local live server: the same rendering, served on the fly instead of written to disk — useful while actively editing a bundle, no manual regeneration step.

Both modes are read-only and localhost-only (no auth/remote-access story needed). Markdown rendering doesn't need to cover full CommonMark — just what OKF bundle bodies actually use (headings, lists, bold/italic, links, code blocks).

Reuses existing building blocks — OKF4net.IndexGenerator, LinkScanner, ConceptSearch, Bundle — no bundle-parsing logic should be duplicated.

Implementation approach — open to discussion

This repo has a hard zero-third-party-dependency rule for the core library and CLI (see CLAUDE.md), with one documented exception (OKF4net.Mcp, which depends on Microsoft.Extensions.Hosting/ModelContextProtocol because it's a leaf tool, not a published library). A viewer needs to pick a lane; three options, roughly in order of "fits current architecture" to "most capable/least effort":

1. Zero-dependency (System.Net.HttpListener) — a new src/OKF4net.Viewer/ project, BCL-only, referencing only OKF4net (same pattern as OKF4net.Catalog). New CLI verbs (e.g. okf render <bundle> --out <dir>, okf serve <bundle> [--port]) delegate to it. Stays fully consistent with the project's dependency policy, at the cost of hand-rolling the HTTP plumbing.
2. ASP.NET Core — same shape, but the server itself uses ASP.NET Core, following the precedent already set for OKF4net.Mcp. Better serving ergonomics (routing, static file middleware, etc.), but it's a new exception to the zero-dependency rule that would need documenting in CLAUDE.md if chosen, and arguably a bigger one than MCP's (this would be reachable from the main CLI, not a separate leaf tool).
3. Standalone web tool (npm/front-end) — a separate front-end project (under web/ or a new samples//tools/ directory) that consumes a bundle via static files or a small JSON endpoint, entirely outside the .NET library/CLI. Zero impact on the core dependency graph, but it's a second toolchain (Node/npm) to maintain and doesn't ship as part of the okf binary.

Markdown-to-HTML rendering in the browser is expected to use a small vendored client-side JS library regardless of which server approach is picked (not a NuGet dependency) — writing a full CommonMark parser server-side isn't the goal here.

Out of scope

• Authentication / remote access — localhost-only.
• Editing bundles through the viewer — read-only.
• Full CommonMark conformance in the rendered output.

Files likely touched

Depends on the approach chosen above; at minimum README.md and CHANGELOG.md for the new capability, plus new project(s) under src/ and/or web//samples/.