fix(desktop): widen transcript code blocks

[liugddx]

Summary

• Keep the shared desktop --maka-chat-measure at 680px, so composer, header notices, hero, interaction, plan, agent-graph, and WorkHub surfaces do not change width.
• Add a transcript-only 800px measure, matching the Astryx AI Chat conversation message area without adopting the unrelated spacious padding and mask semantics.
• Preserve the Astryx Markdown 680px prose measure while allowing code cards to fill the 800px transcript container instead of retaining the 400px fit-content floor.
• Add a focused transcript code-block Storybook scenario for visual review.

Screenshots

Before — 680px transcript/code card:

After — 800px transcript/code card, with prose still capped at 680px:

Scope check

• --maka-chat-measure: unchanged at 680px.
• --maka-transcript-measure: 800px, with one runtime consumer: .maka-turn.
• Measured in the rendered Storybook DOM: turn 800px; Markdown heading/prose measure 680px; code card 800px.
• Narrow windows still resolve .maka-turn { width: 100% } against available inline space.

Verification

• npm run lint — 2660 files, passed.
• npm run format:check — 1605 files, passed.
• npm --workspace @maka/desktop run typecheck:stories — passed.
• npm --workspace @maka/desktop run build-storybook — passed.
• npm --workspace @maka/ui test — 226 passed, 0 failed.
• Storybook transcript code-block scenario rendered at 680px and 800px; both screenshots were visually checked at the same 1200×600 CSS-pixel viewport.
• Full workspace build is currently blocked by the latest upstream main baseline: packages/storage/src/__tests__/codex-session-adapter.test.ts:267 references missing decodeStoredMessage. The same failure occurs in upstream main CI run 32664680331; this PR does not alter that file.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex inspected the reviewer feedback and Astryx package behavior, narrowed the global change to a transcript-only measure, updated the implementation and visual evidence, synchronized current main, and ran verification.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Reviewed exact head 9fe8ec4. Coverage: the shared 680→880px desktop chat measure across transcript, composer, header, hero, interaction/plan/agent-graph consumers and their responsive caps; Markdown CodeBlock width behavior for single-line and multiline fences; Storybook scenario and supplied before/after evidence. Exclusions: live Electron interaction at multiple OS scaling factors and exhaustive visual review of every shared-measure consumer. Local UI→Desktop builds passed and the full UI suite is 217/217 green; hosted exact-head test is green. No P0–P3 findings. The branch is 24 commits behind current main; a current-main merge-tree probe is clean.

[Astro-Han]

Follow-up on the already-published approval, raised by a maintainer after it went out. Not a defect claim and not a retraction of the approval — a request for evidence proportional to the change surface.

The diff is small, but this line is not transcript-scoped. --maka-chat-measure lives on :root and is consumed by the transcript, composer, header, onboarding hero, and the interaction / plan / agent-graph surfaces. Moving it 680px -> 880px is a global layout change delivered through a five-file diff, so fix(desktop): widen transcript code blocks understates what lands.

The existing review verified that every consumer caps itself at the available inline size and that no surface overflows, and it explicitly excluded exhaustive visual regression across those consumers and real multi-scale-factor Electron interaction. That exclusion is exactly where a 200px widening carries its risk: the logical claim has evidence, the appearance claim does not.

Two things would close it:

1. Before/after screenshots for the other --maka-chat-measure consumers, not only the transcript code block — composer, header, hero, and the interaction / plan / agent-graph surfaces. The two screenshots in this PR cover the motivating case only.
2. Either retitle to reflect a global measure change, or split the :root token change into its own PR so the transcript fix can land on its own evidence.

Separately, we are checking what width the upstream Astryx template recommends for an AI chat surface. If the official guidance names a value, this token should agree with it rather than being chosen independently; we will post that finding here when we have it.

[Astro-Han]

Follow-up with the upstream comparison promised in the previous comment. The 880px value has no Astryx basis, and the closest official AI-chat figure is 800px. I verified this against the vendored package rather than taking it second-hand.

• @astryxdesign/cli/assets/templates/pages/ai-chat/page.tsx — the official "AI Chat Conversation" page renders <ChatLayout density="spacious">.
• @astryxdesign/core/src/Chat/ChatLayout.tsx — for that density, both messageAreaSpacious and dockInnerSpacious are capped at maxWidth: 800. That single value bounds the transcript and the composer, which makes it the closest upstream analogue to this repo's shared --maka-chat-measure.

Two nearby values are not an AI-chat recommendation and should not be cited as one:

• Markdown.tsx defaults contentWidth to 680px, but its own documentation scopes that to paragraphs, headings, lists and blockquotes; tables and code blocks are explicitly allowed to fill the container. So 680 is a prose measure, not a transcript/composer width — and notably, upstream's answer to "code fences look cramped" is that code is already exempt from the prose measure, not that the prose measure should grow.
• pages/ai-chat-landing/page.tsx uses contentWidth={720}, but that is the landing/greeting surface, not a conversation transcript.

The theme-neutral package ships no chat or prose width token, and neither this repo's Astryx alignment audits nor the vendored patch mention 880 or anything equivalent.

So the accurate statement is: upstream picked 800 for a conversation surface, 680 for prose, and 880 is this project's own product judgement. That is a legitimate thing to decide — but it has to be carried by product evidence, not by an implied upstream endorsement, and the evidence should cover every --maka-chat-measure consumer rather than the code-block case alone.

On process: the earlier approval on this PR was published before this comparison existed, and the reviewer who issued it has since said it was too strong to stand as merge evidence. This repository does not dismiss reviews, so that approval cannot be withdrawn mechanically — please treat this comment as superseding it. Nothing here is a defect claim about the code; it is a request that the change surface and the evidence match before this lands.

[Astro-Han]

补一条来自 Astryx 官方值的建议（承接前面关于「官方模板宽度是多少」的问题）。

查了 vendored 的 @astryxdesign/core/src/Chat/ChatLayout.tsx：官方 AI Chat Conversation 这一档的宽度是 800px（messageAreaSpacious { maxWidth: 800 } / dockInnerSpacious { maxWidth: 800 }），而当前仓库用的 balanced 档两者都是 maxWidth: '100%'（不设上限）。所以 880 不是官方值，800 才是。

另外有人提过「直接切 <ChatLayout density=\"spacious\">」这条路，我核过之后认为它单独不成立，两个原因：

1. spacious 不是一个纯宽度旋钮：它同时把消息区 paddingInline 0 → --spacing-4、dock 边距 --spacing-3 → --spacing-4、顶部渐隐 100px → 120px、mask ramp 36px → 48px。是一整档间距语义。
2. 覆盖面不够：ChatLayout 只拥有转录区和输入坞内层两处。--maka-chat-measure 的其余消费点（composer.css、hero.css、interaction-prompts.css、plan-mode.css、chat-header.css、agent-graph.css、packages/ui/src/styles.css）都是纯 CSS，不经过 ChatLayout，切 density 之后它们仍停在旧值，界面上会出现两套并存的量度。

这不改变之前那条请求（需要补齐所有消费面的前后对比）；只是把「取哪个数」这一项收敛掉了。

Withdrawing this approval. It was submitted before the review of this PR was complete, and the same reviewer retracted it in a follow-up comment shortly afterwards. Two blocking concerns remain open on this exact head: the before/after evidence across every --maka-chat-measure consumer has not been supplied, and the chosen 880px has no upstream basis (Astryx's official AI Chat Conversation width is 800px). Leaving a green approval attached to this head would misrepresent the review state.

[liugddx]

Addressed the follow-up at exact head 0000bc544fa9949740a73ae4cf3f464d6e8c2acd.

Scope decision

I took the scope-reduction option rather than widening the shared token:

• --maka-chat-measure is restored to and remains at 680px.
• A new --maka-transcript-measure: 800px has exactly one runtime consumer: .maka-turn.
• Composer, header notices, hero, interaction, plan, agent-graph, and the new WorkHub consumer therefore keep their existing 680px behavior; no before/after evidence is needed for surfaces this PR no longer changes.
• The 800px value follows the Astryx AI Chat conversation message-area value. This does not switch to density="spacious", so Maka keeps its existing balanced padding, dock margin, and mask semantics.

This also makes the existing title accurate again: the delivered layout change is transcript-scoped.

Rendered evidence

At the same 1200×600 CSS-pixel Storybook viewport:

• before: transcript turn / code card = 680px;
• after: transcript turn = 800px, Markdown prose heading remains 680px, code card = 800px;
• the code card now fills the transcript via CodeBlock width="100%" instead of Astryx fit-content with its 400px floor.

The PR description now contains regenerated, same-viewport before/after screenshots for the scoped change.

Verification

• npm run lint — 2660 files passed
• npm run format:check — 1605 files passed
• npm --workspace @maka/desktop run typecheck:stories — passed
• npm --workspace @maka/desktop run build-storybook — passed
• npm --workspace @maka/ui test — 226 passed, 0 failed
• git diff --check — passed

Baseline note: the full workspace build currently fails on latest upstream main at packages/storage/src/__tests__/codex-session-adapter.test.ts:267 because decodeStoredMessage is undefined. Upstream main CI run 32664680331 has the same failure; this PR does not touch that path.

Please re-review this exact head.

[Astro-Han]

Approving at a8f65f508ab2a284a9bac8f4cc93398b20acc67c.

The [P2] I raised earlier — the transcript measure token — is fixed at this head: --maka-chat-measure is 680px, --maka-transcript-measure is 800px scoped to .maka-turn, and 880 no longer appears anywhere in maka-tokens.css. That thread is resolved.

Gate at this exact head: hosted test is terminal green (all 38 steps, including Desktop e2e, Browser WebContentsView smoke, Alignment audit, Storybook build and smoke, and the CLI candidate build and validation). Zero unresolved review threads. No APPROVED review is bound to an older commit — the one prior approval was dismissed and has not been re-issued.

Approval only; merging is a human's call.

[liugddx]

Synced main at 3bb645e99 into this branch in merge commit a8f65f508.

The merge brings in the upstream #3656 storage test fix (decodeStoredMessage -> the canonical decoder); it does not change this PR's five-file UI/Storybook diff. The previous CI failure was exactly that upstream storage compile error.

Fresh verification is green:

• CI test 32682456425 passed in 16m15s.
• The run passed build, release contracts, typecheck, affected workspace tests, Runtime Host tests, Desktop E2E, Storybook build/smoke, and installed CLI validation.

The PR is ready for review at exact head a8f65f508ab2a284a9bac8f4cc93398b20acc67c.

[Astro-Han]

One comment-wording request and then this is good to go — the code itself is fine.

The new token comment reads as though 800px were an Astryx-mandated value:

Astryx's AI Chat conversation uses an 800px message area…

That is true only at Astryx's spacious density. Maka's chat surface runs at balanced (packages/ui/src/chat-surface-layout.tsx:37, deliberately letting Astryx's own @default 'balanced' stand), and at balanced — as at compact — the message area resolves to max-width: 100%. Astryx hands width to the host at that density rather than prescribing one.

So 800px is Maka's own choice here, not conformance to an upstream rule. That is a perfectly good choice — it matches the reading width Astryx picks for spacious — but the comment should say so, otherwise a future reader will treat the number as untouchable upstream policy.

Suggested rewording, roughly: at balanced density Astryx leaves the message area at max-width: 100% and delegates width to the host; Maka sets its transcript measure to 800px, matching the value Astryx uses at spacious, while prose stays at 680px and code/tables fill the wider container.

Keep the value; just retire the attribution.

中文

只有一处注释措辞需要改，代码本身没问题。

新加的 token 注释写成了"Astryx 的 AI Chat 会话使用 800px 消息区"，这句话只在 Astryx 的 spacious 密度下成立。Maka 的聊天面跑在 balanced（见 packages/ui/src/chat-surface-layout.tsx:37，当初就是特意让 Astryx 自己的 @default 'balanced' 生效），而 balanced 与 compact 一样，消息区解析为 max-width: 100%——在这个密度下 Astryx 把宽度交给宿主，并没有规定值。

所以 800px 是 Maka 自己的选择，而不是对上游规范的遵循。这个选择没问题（它正好等于 Astryx 在 spacious 下采用的阅读宽度），但注释应当如实说明，否则后来的人会把这个数字当成不可改动的上游政策。

建议改成大意如下：balanced 密度下 Astryx 将消息区保持在 max-width: 100% 并把宽度交给宿主；Maka 自行将 transcript 宽度定为 800px，与 Astryx 在 spacious 下的取值一致，同时 prose 仍为 680px，代码与表格填满容器。

值保留，去掉冒称上游规定的说法即可。

[Astro-Han]

LGTM — merging. Thanks for narrowing this to a transcript-scoped token instead of widening the shared measure, and for writing the 800px provenance into the file.

中文

看过了，合并。感谢改成 transcript 范围的单独 token 而不是加宽共享量度，也感谢把 800px 的来源写进了文件里。