fix(chat): let an ancestor MARKDOWN_VIEW_REGISTRY override markdown views

<chat-streaming-md> provided MARKDOWN_VIEW_REGISTRY on its own component
injector from its own default, so a provider at the application root or on a
route was always shadowed and never reached the markdown node components.
The [viewRegistry] input was the only override that worked.

Resolution is now most-specific-first: the [viewRegistry] input, then a
registry found through skipSelf on an ancestor injector, then
cacheplaneMarkdownViews. The resolved value is still provided on the component
injector, so <chat-md-children> and the table-row view are unchanged, and
<chat> needs to forward nothing for an app-wide override to reach the markdown
it renders for assistant messages.

The new spec fails on the old resolution in two of its four cases (ancestor
provider, and the same through <chat>) and passes on the other two, which pin
the default and the input precedence.

Restores an accurate "App-wide override" section in the markdown guide, which
previously carried a Callout asserting the opposite, and corrects the
CHANGELOG entry that made the same claim.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Author: blove

apps/website/content/docs/chat/guides/markdown.mdx

@@ -126,16 +126,14 @@ Use the exported `markdownDocument(content, delivery)` helper to derive it from
 
 It resolves each markdown node type against `MARKDOWN_VIEW_REGISTRY` — a chat-internal DI token exported from `@threadplane/chat` and consumed by the markdown node components.
 
-Every `<chat-streaming-md>` instance provides `MARKDOWN_VIEW_REGISTRY` on its own
-component injector, from `[viewRegistry]` when you pass one and from
-`cacheplaneMarkdownViews` (the full 26-node registry) otherwise.
-
-<Callout type="warning" title="There is no app-wide markdown override">
-Because the component always provides the token itself, a
-`MARKDOWN_VIEW_REGISTRY` provider in your root or route providers is shadowed and
-never reaches the markdown node components. `[viewRegistry]` on
-`<chat-streaming-md>` is the only override point.
-</Callout>
+Every `<chat-streaming-md>` instance provides the resolved registry on its own
+component injector, so the markdown node components below it read one value.
+Resolution runs most-specific-first:
+
+1. The `[viewRegistry]` input on that `<chat-streaming-md>`.
+2. A `MARKDOWN_VIEW_REGISTRY` provider on an ancestor injector -- your
+   application root or a route.
+3. `cacheplaneMarkdownViews`, the full 26-node registry.
 
 ## Overriding Markdown Components
 
@@ -177,10 +175,38 @@ export class CustomChatComponent {
 Use `overrideViews` when replacing an existing node type. Use `withViews` when adding a brand-new node type that `cacheplaneMarkdownViews` does not yet cover — `withViews` is additive-only and the base registry wins on conflicts. See the [render views API](/docs/render/api/views) for full signatures.
 </Callout>
 
-`<chat>` renders assistant markdown through its own `<chat-streaming-md>`, and
-does not forward a `[viewRegistry]`. To ship a custom node renderer inside a
-conversation, project your own `ai` message template into
-`<chat-message-list>` and mount `<chat-streaming-md [viewRegistry]="…">` there.
+### App-wide override
+
+Provide `MARKDOWN_VIEW_REGISTRY` once and every markdown surface below that
+injector picks it up, including the `<chat-streaming-md>` that `<chat>` mounts
+for assistant messages. `<chat>` forwards nothing, and needs to forward nothing.
+
+```typescript
+// app.config.ts
+import { ApplicationConfig } from '@angular/core';
+import {
+  MARKDOWN_VIEW_REGISTRY,
+  cacheplaneMarkdownViews,
+} from '@threadplane/chat';
+import { overrideViews } from '@threadplane/render';
+import { MyCodeBlockComponent } from './my-code-block.component';
+
+export const appConfig: ApplicationConfig = {
+  providers: [
+    {
+      provide: MARKDOWN_VIEW_REGISTRY,
+      useValue: overrideViews(cacheplaneMarkdownViews, {
+        'code-block': MyCodeBlockComponent,
+      }),
+    },
+  ],
+};
+```
+
+The same provider works in a route's `providers` array when only one section of
+the application should render markdown differently. A `[viewRegistry]` input on
+an individual `<chat-streaming-md>` still wins over both, so a single surface can
+opt out of the application-wide choice.
 
 ## Node-Type Reference
 

libs/chat/CHANGELOG.md

@@ -6,9 +6,13 @@
 
 - **`provideChat()`, `ChatConfig`, and `CHAT_CONFIG` are gone.** No component in the library ever injected the token, so calling `provideChat({})` configured nothing: `renderRegistry`, `avatarLabel`, and `assistantName` were values only your own wrappers could read back. Delete the call and the import; `provideAgent()` from your runtime adapter is the only provider the chat components require, and everything they render is driven by component inputs. If you were reading `CHAT_CONFIG` from your own components, define your own injection token for those values.
 
+### Fixed
+
+- **An application-level `MARKDOWN_VIEW_REGISTRY` provider now takes effect.** `<chat-streaming-md>` provided the token on its own injector from its own default, which shadowed any provider at the application root or on a route. It now resolves most-specific-first — the `[viewRegistry]` input, then an ancestor injector, then `cacheplaneMarkdownViews` — so one root provider overrides markdown rendering across every chat surface, including inside `<chat>`, with nothing to forward.
+
 ### Changed
 
 - **`@angular/forms` peer dependency removed:** `chat-input` now binds its textarea with a direct `[value]`/`(input)` pair (fixes the composer keeping sent text under zoneless + OnPush). `@threadplane/chat` no longer requires `@angular/forms` — consumers may drop it unless they use it themselves.
 - **json-render store isolation:** `<chat>`'s json-render message surfaces no longer fall back to the conversation-wide internal store — each surface self-seeds from its spec's `state` unless you pass an explicit `[store]`. Pass `[store]` (e.g. `signalStateStore({})`) when dashboards should receive backend agent state (STATE_SNAPSHOT) or share live values across surfaces; same-key dashboards in different messages are now isolated by default. Tool views (`chat-tool-views`) keep the previous shared-store behavior.
-- **Public API trim:** `@threadplane/chat` no longer re-exports `provideViews` / `VIEW_REGISTRY` from `@threadplane/render`. Consumers using `<render-spec>` / `<render-element>` directly should import from `@threadplane/render`. For chat's markdown view overrides, pass `overrideViews(cacheplaneMarkdownViews, { … })` from `@threadplane/render` to the `[viewRegistry]` input on `<chat-streaming-md>`. That input is the only override point: the component always provides `MARKDOWN_VIEW_REGISTRY` on its own injector, so an app-level or route-level provider for that token is shadowed and never reaches the markdown node components. The previously-documented `provideViews(withViews(…))` pattern never drove rendering either.
+- **Public API trim:** `@threadplane/chat` no longer re-exports `provideViews` / `VIEW_REGISTRY` from `@threadplane/render`. Consumers using `<render-spec>` / `<render-element>` directly should import from `@threadplane/render`. For chat's markdown view overrides, pass `overrideViews(cacheplaneMarkdownViews, { … })` from `@threadplane/render` to the `[viewRegistry]` input on `<chat-streaming-md>`, or provide the same value for `MARKDOWN_VIEW_REGISTRY` at the application root or on a route to override every markdown surface at once. The previously-documented `provideViews(withViews(…))` pattern never drove rendering.
 - **License:** `@threadplane/chat` is now MIT-licensed for commercial and noncommercial use. The package no longer accepts or checks activation tokens.

libs/chat/src/lib/markdown/markdown-view-registry.ts

@@ -7,10 +7,12 @@ import type { ViewRegistry } from '@threadplane/render';
  * and <md-children>. Maps MarkdownNode.type strings (e.g. "paragraph",
  * "heading") to Angular components that render that node type.
  *
- * `<chat-streaming-md>` provides the runtime registry on its component-level
- * injector — either the consumer-supplied [viewRegistry] input, or
- * `cacheplaneMarkdownViews` (the default) — so descendant <md-children>
- * components resolve the right components for each node.
+ * `<chat-streaming-md>` provides the resolved registry on its component-level
+ * injector so descendant <md-children> components resolve the right component
+ * for each node. It resolves most-specific-first: the `[viewRegistry]` input,
+ * then a registry provided by an ancestor injector (application root or route),
+ * then `cacheplaneMarkdownViews` (the default). Providing this token at the
+ * application root is therefore a supported app-wide override.
  */
 export const MARKDOWN_VIEW_REGISTRY = new InjectionToken<ViewRegistry>(
   'MARKDOWN_VIEW_REGISTRY',

libs/chat/src/lib/streaming/streaming-markdown.component.ts

@@ -127,8 +127,25 @@ export class ChatStreamingMdComponent {
   readonly document = input.required<StreamingMarkdownDocument>();
   readonly viewRegistry = input<ViewRegistry | undefined>(undefined);
 
+  /**
+   * A registry provided further up the injector tree — at the application root
+   * or on a route. `skipSelf` is what makes an app-wide override possible: this
+   * component provides `MARKDOWN_VIEW_REGISTRY` on its own injector for its
+   * descendants, so without it the component would only ever find its own
+   * value and shadow the ancestor.
+   */
+  private readonly ancestorRegistry = inject<ViewRegistry | null>(
+    MARKDOWN_VIEW_REGISTRY,
+    { optional: true, skipSelf: true }
+  );
+
+  /**
+   * Most specific wins: the `[viewRegistry]` input, then a registry provided by
+   * an ancestor injector, then the built-in markdown views.
+   */
   readonly resolvedRegistry = computed(
-    () => this.viewRegistry() ?? cacheplaneMarkdownViews
+    () =>
+      this.viewRegistry() ?? this.ancestorRegistry ?? cacheplaneMarkdownViews
   );
 
   private readonly resolver = inject(CitationsResolverService, {

libs/chat/src/lib/streaming/streaming-markdown.registry-override.spec.ts

@@ -0,0 +1,145 @@
+// libs/chat/src/lib/streaming/streaming-markdown.registry-override.spec.ts
+//
+// WHAT THIS PINS. `<chat-streaming-md>` provides MARKDOWN_VIEW_REGISTRY on its
+// own component injector so `<chat-md-children>` and the table-row view can
+// resolve it. Providing it unconditionally from the component's own default
+// made an application- or route-level provider for the same token unreachable:
+// the component injector always won. Resolution now runs input first, then an
+// ancestor injector, then the built-in default — so an app-wide override
+// actually reaches the markdown node components.
+import { Component, input, signal } from '@angular/core';
+import { TestBed } from '@angular/core/testing';
+import { overrideViews, type ViewRegistry } from '@threadplane/render';
+import { describe, expect, it } from 'vitest';
+import { cacheplaneMarkdownViews } from '../markdown/cacheplane-markdown-views';
+import { MARKDOWN_VIEW_REGISTRY } from '../markdown/markdown-view-registry';
+import { ChatComponent } from '../compositions/chat/chat.component';
+import { staticDelivery } from '../agent/message-delivery';
+import { mockAgent } from '../testing/mock-agent';
+import {
+  ChatStreamingMdComponent,
+  type StreamingMarkdownDocument,
+} from './streaming-markdown.component';
+
+@Component({
+  standalone: true,
+  selector: 'test-loud-paragraph',
+  template: `<p class="loud-paragraph"><ng-content /></p>`,
+})
+class LoudParagraphComponent {
+  /** The markdown node the registry binds onto every view component. */
+  readonly node = input<unknown>();
+}
+
+const customViews = (): ViewRegistry =>
+  overrideViews(cacheplaneMarkdownViews, {
+    paragraph: LoudParagraphComponent,
+  });
+
+const doc = (content: string): StreamingMarkdownDocument => ({
+  generation: 'g1',
+  phase: 'complete',
+  content,
+});
+
+@Component({
+  standalone: true,
+  imports: [ChatStreamingMdComponent],
+  template: `<chat-streaming-md [document]="document()" />`,
+})
+class PlainHost {
+  readonly document = signal(doc('Hello world'));
+}
+
+@Component({
+  standalone: true,
+  imports: [ChatStreamingMdComponent],
+  template: `<chat-streaming-md
+    [document]="document()"
+    [viewRegistry]="registry()"
+  />`,
+})
+class InputHost {
+  readonly document = signal(doc('Hello world'));
+  readonly registry = signal<ViewRegistry | undefined>(undefined);
+}
+
+@Component({
+  standalone: true,
+  imports: [ChatComponent],
+  template: `<chat [agent]="agent" />`,
+})
+class ChatHost {
+  readonly agent = mockAgent({
+    messages: [
+      {
+        id: 'm1',
+        role: 'assistant',
+        content: 'Hello world',
+        delivery: staticDelivery('m1'),
+      },
+    ],
+  });
+}
+
+describe('<chat-streaming-md> markdown view registry resolution', () => {
+  it('uses the built-in default when nothing overrides it', () => {
+    const fixture = TestBed.createComponent(PlainHost);
+    fixture.detectChanges();
+
+    expect(
+      fixture.nativeElement.querySelector('.loud-paragraph')
+    ).toBeNull();
+    expect(fixture.nativeElement.querySelector('p')).toBeTruthy();
+  });
+
+  it('uses a registry provided by an ancestor injector', () => {
+    TestBed.configureTestingModule({
+      providers: [
+        { provide: MARKDOWN_VIEW_REGISTRY, useValue: customViews() },
+      ],
+    });
+
+    const fixture = TestBed.createComponent(PlainHost);
+    fixture.detectChanges();
+
+    expect(
+      fixture.nativeElement.querySelector('.loud-paragraph'),
+      'an app-level MARKDOWN_VIEW_REGISTRY must reach the markdown nodes'
+    ).toBeTruthy();
+  });
+
+  it('lets the [viewRegistry] input win over an ancestor provider', () => {
+    TestBed.configureTestingModule({
+      providers: [
+        { provide: MARKDOWN_VIEW_REGISTRY, useValue: customViews() },
+      ],
+    });
+
+    const fixture = TestBed.createComponent(InputHost);
+    fixture.componentInstance.registry.set(cacheplaneMarkdownViews);
+    fixture.detectChanges();
+
+    expect(
+      fixture.nativeElement.querySelector('.loud-paragraph'),
+      'the explicit input is the most specific override'
+    ).toBeNull();
+    expect(fixture.nativeElement.querySelector('p')).toBeTruthy();
+  });
+
+  it('reaches markdown rendered inside <chat> without forwarding anything', () => {
+    TestBed.configureTestingModule({
+      providers: [
+        { provide: MARKDOWN_VIEW_REGISTRY, useValue: customViews() },
+      ],
+    });
+
+    const fixture = TestBed.createComponent(ChatHost);
+    fixture.detectChanges();
+
+    expect(
+      fixture.nativeElement.querySelector('.loud-paragraph'),
+      '<chat> renders assistant markdown through <chat-streaming-md>'
+    ).toBeTruthy();
+  });
+});