Hero Composer lacks an additive public dock below the zero-turn InputBar

[yunmin311]

Context

The public Composer extension surface is currently asymmetric between active conversations and blank / zero-turn Hero sessions.

Active conversations expose an additive seat below the Composer through:

conversation.composer.dock

The resident Hero Composer has no equivalent public seat that is additive, below the InputBar, rendered in normal document flow, and does not replace the Composer.

Why the existing seams are not equivalent

1. conversation.input.dock

   • renders before the InputBar
   • semantically represents content above the Composer

2. conversation.input.overlay

   • is an internal popup / overlay anchor within the InputBar
   • does not provide below-Composer normal flow

3. conversation.composer.dock

   • has the desired additive dock semantics
   • is mounted only for the active variant === 'composer' path

4. conversation.composer

   • is a replacement chain
   • using it would replace the resident Composer rather than extend it

As a result, an extension that needs lightweight contextual UI below the zero-turn Composer currently has to rely on DOM positioning, replace the Composer, use private APIs, or maintain a host patch. None of those options fit the public extension model.

Proposed contract

'conversation.hero.composer.dock': {
  kind: 'list'
  scope: 'session'
}

Expected behavior

• mounts only for a blank / zero-turn Hero with a real Session and live input
• renders immediately after the resident Hero InputBar in normal document flow
• additive; does not replace the resident Composer
• not an overlay
• absent in no-session state
• absent in active conversations
• preserves list registration order
• leaves existing conversation.composer.dock behavior unchanged

Compatibility

This would be an additive public API change. Existing conversation.composer.dock registrations would remain active-composer-only and would not gain Hero behavior implicitly.

Reference implementation

A minimal implementation and focused regression tests are available as design evidence:

• branch: https://github.com/yunmin311/deepseek-harness/tree/feat/hero-composer-dock
• comparison: master...yunmin311:deepseek-harness:feat/hero-composer-dock
• commit: 64c3528282c09412ea6fec57b968c6109d492715

Validation on that reference branch:

• ui-conversation targeted: 91/91 passed
• package/adjacent: 429/429 passed
• typecheck: passed
• lint: passed
• production build: passed
• slot catalog, bilingual docs, and pairing validation: passed
• GUI suite: 5331 passed, 1 skipped, 1 failed
• doc-sync: 33/34 gates passed

The two local failures occur while creating Windows symbolic links (EPERM) before their business assertions. Those test files are outside the reference patch diff.