## 作成 LocalTicketBackend によって作成されました。 --- ## Intake summary チャットビューの TUI で Markdown pipe table が読み取り可能に描画できない不具合を bug Ticket として整理した。対象 surface は通常の chat / conversation view に限定し、session history / Pod metadata / worker history / prompt context は変更しないことを invariant とした。通常の pipe table 表示、既存 Markdown/plain text の非退行、狭い terminal での安全な表示、関連テストまたは手動確認を受け入れ条件にしている。 --- ## State changed 要件・受け入れ条件・invariant・validation が揃っており、Orchestrator が implementation routing できる状態になった。 --- ## State changed Ticket を `workspace-panel` が queued にしました。 --- ## State changed Accepted queued implementation after reading the Ticket and current workspace state. This is a bounded TUI chat rendering bug fix and is independent of the active Ticket backend/orchestration-plan worktree, so it can proceed in a separate worktree without overlapping source surfaces beyond normal validation. --- ## Decision Routing decision: implementation_ready Reason: - The Ticket is scoped to the normal TUI chat/conversation view and has concrete acceptance criteria for pipe-table readability, non-regression, narrow terminal behavior, and tests/manual confirmation. - It explicitly excludes Pod/session/history/context changes and non-chat surfaces. - Current active implementation work is in Ticket backend/orchestration-plan tooling; this TUI rendering fix has low source-conflict risk and can proceed in a separate worktree. IntentPacket: Intent: - Make ordinary Markdown pipe tables in assistant chat messages readable in the TUI conversation view without changing persisted history or model context. Binding decisions / invariants: - Only display/rendering behavior should change; do not mutate Pod history, session logs, worker history, prompt context, or stored message text for rendering. - Target the normal chat/conversation view. Do not treat this as a Ticket panel, `yoi ticket show`, docs rendering, or WebFetch extraction feature. - Do not pursue full GitHub Flavored Markdown table compatibility unless it falls out naturally from a small implementation; ordinary pipe tables are the acceptance target. - Rendering must be robust: malformed or too-wide tables should not panic, drop message content, or break the surrounding message block. - Preserve existing behavior for non-table Markdown/plain text as much as possible. - Avoid broad rendering abstraction rewrites or new large parser dependencies unless investigation proves they are necessary; escalate first if so. Implementation latitude: - Coder may either add explicit table handling to the existing Markdown renderer or normalize table blocks into a readable plain-text fallback within the rendering layer. - Column width/alignment/wrapping can be pragmatic and constrained by the existing TUI line/wrap model. - Add unit/snapshot-like tests around the rendering function or a narrow test fixture for chat message rendering. If interactive manual verification is needed, include exact steps in the implementation report. Escalate if: - A large Markdown parser dependency or public rendering API redesign is needed. - The change requires touching broad TUI surfaces outside chat/conversation rendering. - Correctness would require changing stored message/history representation. Validation: - Focused TUI Markdown/chat rendering tests covering a simple pipe table and non-table regression. - Narrow-terminal/wrapping safety test if feasible. - Relevant `cargo test -p tui ...` target(s). - `cargo fmt --check`. - `git diff --check`. - `cargo check --workspace`. - `nix build .#yoi` before final completion because TUI/package behavior changes. ---