richlander · richlander · Mar 11, 2026 · Feb 23, 2026 · Feb 23, 2026 · Feb 24, 2026
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -206,24 +206,37 @@ jobs:
           grep -q "## Package Dependencies" smoke-package-normal.md
           grep -q "Library" smoke-package-normal.md
 
-      - name: Smoke test - type command
+      - name: Smoke test - type command (oneline default)
         run: |
-          dotnet-inspect type --package System.Text.Json@10.0.0 -t 5 > smoke-type.md
+          dotnet-inspect type --package System.Text.Json@10.0.0 -t 5 > smoke-type.txt
+          cat smoke-type.txt
+          grep -q "JsonSerializer" smoke-type.txt
+
+      - name: Smoke test - member command (oneline default)
+        run: |
+          dotnet-inspect member JsonSerializer --package System.Text.Json@10.0.0 -m 5 > smoke-member.txt
+          cat smoke-member.txt
+          grep -q "Serialize" smoke-member.txt
+          grep -q "Deserialize" smoke-member.txt
+
+      - name: Smoke test - type command (markdown)
+        run: |
+          dotnet-inspect type --package System.Text.Json@10.0.0 -v:m -t 5 > smoke-type.md
           cat smoke-type.md
           grep -q "JsonSerializer" smoke-type.md
 
-      - name: Smoke test - member command
+      - name: Smoke test - member command (markdown)
         run: |
-          dotnet-inspect member JsonSerializer --package System.Text.Json@10.0.0 -m 5 > smoke-member.md
+          dotnet-inspect member JsonSerializer --package System.Text.Json@10.0.0 -v:m -m 5 > smoke-member.md
           cat smoke-member.md
           grep -q "JsonSerializer" smoke-member.md
           grep -q "Serialize" smoke-member.md
           grep -q "Deserialize" smoke-member.md
 
       - name: Smoke test - platform command
         run: |
-          dotnet-inspect platform list > smoke-platform.md || true
-          cat smoke-platform.md
+          dotnet-inspect platform list > smoke-platform.txt || true
+          cat smoke-platform.txt
 
       - name: Validate markdown output
         run: |

diff --git a/README.md b/README.md
@@ -17,7 +17,7 @@ dnx dotnet-inspect -y -- <command>
 ## Quick Reference
 
 | Command | Purpose |
-|---------|---------|
+| --------- | --------- |
 | `package X` | Package metadata, dependencies, files, versions |
 | `library X` | Library metadata, symbols, SourceLink audit, dependency tree |
 | `type` | Discover types (terse, no docs) — use `--shape` for hierarchy |
@@ -28,7 +28,6 @@ dnx dotnet-inspect -y -- <command>
 | `find X` | Search for types across packages, frameworks, and local assets |
 | `samples X` | Fetch and display code samples |
 | `platform` | List installed frameworks |
-| `cli` | CLI args explorer (tree view) |
 
 ### Bare Names
 
@@ -37,7 +36,7 @@ A bare name like `dotnet-inspect System.Text.Json` uses a router to pick the bes
 ### Common Flags
 
 | Flag | Description |
-|------|-------------|
+| ------ | ------------- |
 | `-v:q/m/n/d` | Verbosity: quiet, minimal (default), normal, detailed |
 | `--platform` | Search all platform frameworks (find, extensions, implements) |
 | `--json` | JSON output |
@@ -224,12 +223,13 @@ dotnet-inspect cache                                # Show cache size breakdown
 dotnet-inspect cache --clean                        # Clear the cache
 ```
 
-### cli
+### Help Tree View
 
 ```bash
-dotnet-inspect cli                                  # Tree view (single level)
-dotnet-inspect cli -v:d                             # Deep view (all levels)
-dotnet-inspect cli api                              # Specific command with options
+dotnet-inspect -v:m                                 # Tree view (command names + descriptions)
+dotnet-inspect -v:n                                 # Tree view (commands, args, options)
+dotnet-inspect -v:d                                 # Deep view (all levels with descriptions)
+dotnet-inspect -v:q                                 # Command names only (oneliner)
 ```
 
 ## Output Control

diff --git a/docs/data/README.md b/docs/data/README.md
@@ -13,7 +13,7 @@ Top NuGet packages by download count, sourced from <https://www.nuget.org/stats/
 Flat lists of `.dll` filenames shipped with .NET 10.0. One filename per line (e.g. `System.Collections.dll`). Used to identify which assemblies belong to each platform pack, enabling de-duplication when resolving packages.
 
 | File | Source | Count |
-|------|--------|-------|
+| ------ | -------- | ------- |
 | `Microsoft.NETCore.App.Shared.txt` | `/usr/lib/dotnet/shared/Microsoft.NETCore.App/` | 172 |
 | `Microsoft.AspNetCore.App.Shared.txt` | `/usr/lib/dotnet/shared/Microsoft.AspNetCore.App/` | 141 |
 | `Microsoft.NETCore.App.Ref.txt` | `/usr/lib/dotnet/packs/Microsoft.NETCore.App.Ref/` | 167 |

diff --git a/docs/demo-queries.md b/docs/demo-queries.md
@@ -10,19 +10,19 @@ These queries power the `demo` command (`dotnet-inspect demo`).
 ## 1. Shape: INumber\<TSelf> — generic math interface
 
 ```bash
-dotnet-inspect api System.Runtime "INumber<TSelf>" --shape
+dotnet-inspect type "System.Numerics.INumber<TSelf>"
 ```
 
 Shows the full type shape diagram for the `INumber<TSelf>` generic math interface.
 The self-referential constraint (`TSelf : INumber<TSelf>`), 23 implemented interfaces
 with varying type parameter combinations (`IAdditionOperators<TSelf, TSelf, TSelf>`,
 `IComparisonOperators<TSelf, TSelf, bool>`), and operator methods make this the
-ultimate showcase for `--shape` on an interface.
+ultimate showcase for the `type` command's shape view on an interface.
 
 ## 2. Shape: Int128 — generic math concrete type
 
 ```bash
-dotnet-inspect api System.Runtime Int128 --shape
+dotnet-inspect type Int128 --platform System.Runtime
 ```
 
 The concrete counterpart to demo #1. `Int128` is a struct implementing 31 generic
@@ -34,28 +34,28 @@ generic math hierarchy resolved with concrete types
 ## 3. Shape: ValueTuple — Create staircase
 
 ```bash
-dotnet-inspect api System.Runtime ValueTuple --shape
+dotnet-inspect type ValueTuple --platform System.Runtime
 ```
 
 The `ValueTuple` factory class has 9 `Create` overloads that grow from zero to
-eight type parameters, producing a visual staircase in the `--shape` output.
+eight type parameters, producing a visual staircase in the shape output.
 The 8-parameter version wraps into `ValueTuple<T1,...,T7,ValueTuple<T8>>` —
 showing how the runtime handles arbitrary-length tuples via nesting.
 
-## 4. API: JsonSerializer members
+## 4. Members: JsonSerializer
 
 ```bash
-dotnet-inspect api System.Text.Json JsonSerializer
+dotnet-inspect member JsonSerializer --package System.Text.Json
 ```
 
 Lists all public members of `JsonSerializer` — one of the most-used types in
 modern .NET. Shows overload grouping, return types, and parameter signatures.
-Good intro to the `api` command at member granularity.
+Good intro to the `member` command at member granularity.
 
 ## 5. Code: OptionsFactory.Create — source, lowered C#, and IL
 
 ```bash
-dotnet-inspect api --package Microsoft.Extensions.Options OptionsFactory Create
+dotnet-inspect member OptionsFactory --package Microsoft.Extensions.Options -m Create
 ```
 
 Shows the member detail page for `OptionsFactory<TOptions>.Create` — the

diff --git a/docs/design/auto-schema.md b/docs/design/auto-schema.md
@@ -0,0 +1,128 @@
+# Auto-generated DocumentSchema
+
+The discovery system (`-D`, `--fields`, `--columns`) uses `DocumentSchema` to answer
+questions about what sections and items a view model contains. Previously, each command
+maintained a hand-written `CreateSchemaMap()` method that duplicated information already
+captured by Markout's source generator. This doc describes the replacement: a bridge
+method that derives `DocumentSchema` automatically from the source-generated schema.
+
+## Problem
+
+Adding or renaming a section required touching two places:
+
+1. The view model class (Markout attributes like `[MarkoutSection]`)
+2. The manual `CreateSchemaMap()` in the section descriptors file
+
+These could drift. The Markout source generator already walks the same attributes to
+emit serialization code and `MarkoutSchemaInfo` metadata. The schema map was a redundant
+second source of truth.
+
+## Solution: `MarkoutSchemaInfo.ToDocumentSchema()`
+
+A single method on `MarkoutSchemaInfo` that converts the source-generated rendering
+metadata into a `DocumentSchema`:
+
+```csharp
+var schema = MarkoutContext.Default
+    .GetSchemaInfo<LibraryInspectionView>()!
+    .ToDocumentSchema();
+```
+
+This replaces all four `CreateSchemaMap()` methods and their 10 call sites.
+
+### Rendering string → DocumentSchema mapping
+
+The source generator produces rendering strings like `H2 Section "Dependencies" (table)`.
+`ToDocumentSchema()` parses the section name and parenthetical content type, then maps
+to the appropriate `DocumentSchema.Add()` call:
+
+| Content type | ItemKind | Items source |
+| ------------ | -------- | ------------ |
+| `(table)` | `column` | Children with `Column` rendering → DisplayName |
+| `(subsections)` | `column` | Children with `Column` rendering → DisplayName |
+| `(field)` | `field` | The property's own DisplayName |
+| `(fields)` | `field` | Nested children with `Field` rendering (recursive) |
+| `(tree)` | `tree` | Children with `Column` rendering → DisplayName |
+| `(field table)` | — | Section only (dynamic FieldCollection) |
+| `(code block)` | — | Section only (no queryable items) |
+| `(bar chart)` | — | Section only |
+| `(distribution)` | — | Section only |
+| no parens | — | Section only (e.g. bullet list) |
+
+### Duplicate section merging
+
+Multiple properties can share the same section name. For example, `TypeView` has 7+
+properties all mapped to "Constructors" (table, docs table, overloads, code sections).
+When a section name appears again, items are merged (union preserving order, deduplicated
+case-insensitively). If an earlier property was section-only (e.g. code block) and a later
+one has items (e.g. table with columns), the item kind is upgraded.
+
+### Known limitations vs manual schemas
+
+| Aspect | Manual | Auto-generated |
+| ------ | ------ | -------------- |
+| Field table sections (Summary, Package) | Explicit field names | Section-only (dynamic content) |
+| Bullet list sections (Files, Non-normalized Paths) | Explicit item name | Section-only (no column metadata) |
+| Tree sections (Dependencies, Library Refs Transitive) | Explicit item name | Section-only (TreeNode has no columns) |
+| New sections/fields added to view models | Manual update needed | Automatic |
+| Removed sections/fields | Manual cleanup needed | Automatic |
+
+The "section-only" entries still appear in `-D` discovery output. The only loss is
+item-level drill-down for these sections, which was manually fabricated anyway
+(e.g. the manual schema listed "Path" as an item for Files, but that name didn't
+correspond to any queryable property).
+
+### Improvements over manual schemas
+
+The auto-generated schemas are more accurate in several places:
+
+- **Symbols** section now includes Warning and Recommendation fields
+- **Vulnerabilities** correctly shows column names from PackageVulnerability
+  (Severity, Cve Id, Summary, Advisory Url, Ghsa Id) instead of a fake list item
+- **TypeView** sections include Select, Description, Overloads, and other columns
+  that were missing from the manual schema
+- **Type Forwarders** section correctly appears in CliApiSurface
+- **Missing Source Files** section now discoverable (was absent from manual map)
+
+## Files changed
+
+### Markout (upstream library)
+
+- `src/Markout/MarkoutSchemaInfo.cs` — Added `ToDocumentSchema()` and private helpers
+- `tests/Markout.Tests/ProjectionTests.cs` — 9 tests covering all content type mappings,
+  section merging, and edge cases
+
+### dotnet-inspect
+
+**Replaced** (10 call sites across 5 files):
+
+- `Commands/PackageCommand.cs` — 3 sites
+- `Commands/AssemblyCommand.cs` — 2 sites
+- `Commands/ApiCommand.cs` — 1 site (type + member schemas)
+- `CommandLine/Commands/RouterCommandDefinition.cs` — 1 site
+- `CommandLine/Commands/ApiCommandDefinitions.cs` — 2 sites
+
+**Deleted** (4 methods across 3 files):
+
+- `Sections/LibrarySections.CreateSchemaMap()`
+- `Sections/PackageSectionDescriptors.CreateSchemaMap()`
+- `Sections/ApiTypeSectionDescriptors.CreateSchemaMap()`
+- `Sections/ApiMemberSectionDescriptors.CreateSchemaMap()`
+
+## View model → schema mapping
+
+| Call site pattern | View type |
+| ----------------- | --------- |
+| `MarkoutContext.Default.GetSchemaInfo<LibraryInspectionView>()!.ToDocumentSchema()` | Library command |
+| `MarkoutContext.Default.GetSchemaInfo<InspectionResultView>()!.ToDocumentSchema()` | Package command |
+| `MarkoutContext.Default.GetSchemaInfo<CliApiSurface>()!.ToDocumentSchema()` | API type-list |
+| `MarkoutContext.Default.GetSchemaInfo<TypeView>()!.ToDocumentSchema()` | API type-detail |
+
+## Relationship to schema-query design doc
+
+The [schema-query](schema-query.md) doc described a five-step implementation path.
+This change completes step 4 (source-generated schema) by implementing
+`ToDocumentSchema()` as a runtime bridge rather than extending the source generator
+itself. The generator already emits the rendering metadata; the bridge method converts
+it at runtime. This avoids generator changes while achieving the same goal: one source
+of truth for both rendering and querying.
diff --git a/docs/design/command-model.md b/docs/design/command-model.md
@@ -9,7 +9,7 @@ This document describes the conceptual model of dotnet-inspect commands. It serv
 dotnet-inspect works with .NET libraries. There are three ways to specify where a library comes from:
 
 | Command | Source | Example |
-|---------|--------|---------|
+| --------- | -------- | --------- |
 | `package X` | NuGet package | `package System.Text.Json` |
 | `platform X` | Local SDK/runtime | `platform System.Text.Json` |
 | `library ./path` | Local file | `library ./bin/MyLib.dll` |
@@ -21,7 +21,7 @@ These commands accept the same inspection flags (`--audit`, `--sourcelink`, `--a
 Once you've specified a source, flags control what information to show:
 
 | Flag | Shows |
-|------|-------|
+| ------ | ------- |
 | `--library` | Library metadata (version, TFM, architecture) |
 | `--sourcelink` | SourceLink presence and URL (fast, no verification) |
 | `--audit` | Full provenance verification (SourceLink reachability, determinism) |
@@ -42,7 +42,7 @@ dotnet inspect audit ./artifacts/*.nupkg     # nupkg files
 ```
 
 | Verbosity | Output |
-|-----------|--------|
+| ----------- | -------- |
 | `-v:q` | One-line pass/fail for each check |
 | `-v:n` | Audit table with source coverage summary |
 | `-v:d` | Full details including missing source files |
@@ -130,7 +130,7 @@ When commands or flags are deprecated:
 
 Current deprecations:
 
-| Deprecated | Use Instead | Removal Target |
-|------------|-------------|----------------|
-| `package X --metadata` | `library X` | 0.3.0 |
-| `--strict` | `--audit` (now always strict) | 0.3.0 |
+| Deprecated             | Use Instead                   | Removal Target |
+| ---------------------- | ----------------------------- | -------------- |
+| `package X --metadata` | `library X`                   | 0.3.0          |
+| `--strict`             | `--audit` (now always strict) | 0.3.0          |
diff --git a/docs/design/decompiler.md b/docs/design/decompiler.md
@@ -323,14 +323,14 @@ reasonably interpretable.
 The pipeline is designed for graceful degradation. Each phase catches exceptions
 at the method level and falls back to shallower output:
 
-| Failure point          | Fallback                                            |
-| ---------------------- | --------------------------------------------------- |
-| CFG construction       | Emit flat IL (no block structure)                   |
-| Stack simulation       | Emit IL with CFG blocks but no type annotations     |
-| ILAst construction     | Emit annotated IL only (skip lowered C# section)    |
-| Control flow structuring | Emit flat ILAst as sequential statements + goto   |
-| C# emission            | Emit `/* unsupported: opcode */` comment inline     |
-| Individual expression  | Emit `/* opcode arg1 arg2 */` and continue          |
+| Failure point            | Fallback                                            |
+| ------------------------ | --------------------------------------------------- |
+| CFG construction         | Emit flat IL (no block structure)                   |
+| Stack simulation         | Emit IL with CFG blocks but no type annotations     |
+| ILAst construction       | Emit annotated IL only (skip lowered C# section)    |
+| Control flow structuring | Emit flat ILAst as sequential statements + goto     |
+| C# emission              | Emit `/* unsupported: opcode */` comment inline     |
+| Individual expression    | Emit `/* opcode arg1 arg2 */` and continue          |
 
 In practice, the stress test against CoreLib's ~39K methods exercises the full
 pipeline with zero failures. NuGet packages in the wild are messier (obfuscated
@@ -385,14 +385,14 @@ in the output rather than propagating exceptions.
 
 ### Test sources
 
-| Source                     | License | Usage                                        |
-| -------------------------- | ------- | -------------------------------------------- |
-| ILSpy test suite           | MIT     | Test cases, expected output                  |
-| dotnet/runtime IL tests    | MIT     | IL verification test corpus                  |
+| Source                     | License | Usage                                                        |
+| -------------------------- | ------- | ------------------------------------------------------------ |
+| ILSpy test suite           | MIT     | Test cases, expected output                                  |
+| dotnet/runtime IL tests    | MIT     | IL verification test corpus                                  |
 | dotnet/runtime interpreter | MIT     | IL pattern coverage (generics, delegates, constrained calls) |
-| dnSpyEx                    | GPL     | Test inspiration only (never shipped)        |
-| Hand-written samples       | N/A     | `CfgSampleClass` in test project             |
-| Platform assemblies        | N/A     | Stress tests against System.Private.CoreLib  |
+| dnSpyEx                    | GPL     | Test inspiration only (never shipped)                        |
+| Hand-written samples       | N/A     | `CfgSampleClass` in test project                             |
+| Platform assemblies        | N/A     | Stress tests against System.Private.CoreLib                  |
 
 ## Usage workflow