@researai/deepscientist 1.5.0 → 1.5.2

package/src/skills/review/SKILL.md

@@ -0,0 +1,295 @@
+---
+name: review
+description: Use when a draft, paper, or paper-like report is substantial enough for an independent skeptical audit before finalization, rebuttal, or revision routing.
+---
+
+# Review
+
+Use this skill when the quest already has a substantial draft, paper, or paper-like report and now needs an independent, skeptical, evidence-grounded audit.
+
+This is not the same as ordinary `write`.
+It is also not the same as `rebuttal`.
+
+- `write` turns accepted evidence into a narrative.
+- `review` audits that narrative like a harsh but constructive expert reviewer.
+- `rebuttal` responds to concrete external reviewer pressure that already exists.
+
+## Interaction discipline
+
+- Treat `artifact.interact(...)` as the main long-lived communication thread across TUI, web, and bound connectors.
+- If `artifact.interact(...)` returns queued user requirements, treat them as the highest-priority user instruction bundle before continuing the review pass.
+- Immediately follow any non-empty mailbox poll with another `artifact.interact(...)` update that confirms receipt; if the request is directly answerable, answer there, otherwise say the current subtask is paused, give a short plan plus nearest report-back point, and handle that request first.
+- Emit `artifact.interact(kind='progress', reply_mode='threaded', ...)` only when there is real user-visible progress: the first meaningful signal of the review pass, a meaningful checkpoint, or an occasional keepalive during truly long work. Do not update by tool-call cadence.
+- Keep progress updates chat-like and easy to understand: say what changed, what it means, and what happens next.
+- Default to plain-language summaries. Do not mention file paths, artifact ids, branch/worktree ids, session ids, raw commands, or raw logs unless the user asks or needs them to act.
+- Use `reply_mode='blocking'` only for real user decisions that cannot be resolved from local evidence.
+- For any blocking decision request, provide 1 to 3 concrete options, put the recommended option first, explain each option's actual content plus pros and cons, and wait up to 1 day when feasible. If the blocker is a missing external credential or secret that only the user can provide, keep the quest waiting, ask the user to supply it or choose an alternative, and do not self-resolve; if resumed without that credential and no other work is possible, a long low-frequency wait such as `bash_exec(command='sleep 3600', mode='await', timeout_seconds=3700)` is acceptable. Otherwise choose the best option yourself and notify the user of the chosen option if the timeout expires.
+- When the review report, revision plan, or follow-up experiment TODO list becomes durable, send a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what the main risks are, what should be fixed next, and whether the next route is writing, experiment, or claim downgrade.
+
+## Purpose
+
+`review` is an auxiliary audit skill for paper-like deliverables.
+
+It should convert “the draft feels almost done” into a durable, skeptical, technically grounded review workflow:
+
+1. identify the core claims and likely rejection reasons
+2. audit novelty, value, rigor, clarity, and evidence sufficiency
+3. write a reliable review note, not vague prose
+4. produce a concrete revision plan
+5. produce a follow-up experiment TODO list only when the paper truly needs more evidence
+6. route the next step cleanly to `write`, `analysis-campaign`, `baseline`, `scout`, or `decision`
+
+Default review stance: independent audit before celebration.
+Do not treat “looks polished” as “is defensible”.
+
+## Use when
+
+- a substantial `paper/draft.md`, report draft, or paper-like manuscript already exists
+- the quest has enough evidence to support a real audit rather than just speculative comments
+- the user asks for:
+  - a harsh review
+  - a reliable paper audit
+  - revision advice before submission
+  - a decision about whether more experiments are still needed
+- the writing line feels close to done and you need a skeptical gate before stopping
+
+## Do not use when
+
+- the quest still lacks a meaningful draft or report
+- the task is ordinary drafting from evidence
+- concrete external reviewer comments already exist and the real task is response / revision
+  - in that case use `rebuttal`
+
+## Non-negotiable rules
+
+- Review independently. Do not simply mirror previous self-review notes.
+- Do not fabricate praise, flaws, citations, novelty overlaps, or fatal defects.
+- Keep every serious criticism evidence-grounded.
+- Do not recommend more experiments when the real problem is wording, positioning, or claim scope.
+- Do not recommend rhetoric when the real problem is missing evidence.
+- If novelty or positioning is uncertain, treat that as a literature-audit question first, not an automatic experiment request.
+- If a claim is too broad for the evidence, prefer narrowing or downgrading the claim over defending it with style.
+
+## Primary inputs
+
+Use, in roughly this order:
+
+- the current paper or report draft
+- the selected outline if one exists
+- the claim-evidence map if one exists
+- the six-field `evaluation_summary` blocks from recent main experiments and analysis slices
+- recent main and analysis experiment results
+- figures, tables, and captions
+- prior self-review or reviewer-first notes as low-trust auxiliary input
+- nearby papers when novelty or comparison is unclear
+
+If the draft/result state is still unclear, open `intake-audit` first before continuing the review workflow.
+Before proposing extra experiments, read those structured `evaluation_summary` blocks first so you do not request work that the recorded evidence already resolved.
+
+## Core outputs
+
+The review pass should usually leave behind:
+
+- `paper/review/review.md`
+- `paper/review/revision_log.md`
+- `paper/review/experiment_todo.md`
+
+Use the templates in `references/` when needed:
+
+- `review-report-template.md`
+- `revision-log-template.md`
+- `experiment-todo-template.md`
+
+## Review dimensions
+
+Audit at least these dimensions:
+
+- research question and value
+- novelty and positioning
+- method-to-problem fit
+- evidence sufficiency
+- experimental validity and baseline comparability
+- claim scope and over-claiming risk
+- writing defensibility and logical flow
+- figure / table usefulness
+- submission readiness
+
+## Workflow
+
+### 1. Plan the audit
+
+Before writing the review itself, make the audit explicit.
+
+Identify:
+
+- 1 to 3 core claims such as `C1`, `C2`, `C3`
+- the strongest current evidence
+- the weakest current evidence
+- the top 3 likely rejection reasons
+- whether the likely next route is:
+  - text revision
+  - literature / novelty audit
+  - baseline recovery
+  - supplementary experiment
+  - claim downgrade
+
+### 2. Check novelty and positioning only when needed
+
+If novelty, related-work coverage, or field positioning is unclear:
+
+1. open `scout`
+2. run a focused literature / comparison audit
+3. record what is genuinely overlapping, what remains novel, and what is merely better positioned writing
+
+Do not request new experiments just to answer a literature-positioning question.
+
+### 3. Write a reliable review report
+
+Write `paper/review/review.md` using `references/review-report-template.md`.
+
+The review should be:
+
+- independent
+- skeptical but constructive
+- technically specific
+- reader-aware
+- evidence-grounded
+
+At minimum, the review report should cover:
+
+- summary
+- strengths
+- weaknesses
+- key issues
+- actionable suggestions
+- storyline / outline advice
+- priority revision plan
+- experiment inventory and research experiment plan
+- novelty verification and related-work matrix
+- references
+
+If helpful, include an internal conservative overall judgment or score, but do not pretend numerical precision when evidence is still unstable.
+
+### 4. Produce the revision log
+
+Write `paper/review/revision_log.md` using `references/revision-log-template.md`.
+
+For each serious issue, record:
+
+- issue id
+- why it matters
+- what should change
+- whether the fix is writing-only, evidence-only, or experiment-dependent
+- whether the issue blocks `finalize`
+
+### 5. Produce the follow-up experiment TODO list
+
+Only if more evidence is truly needed, write `paper/review/experiment_todo.md` using `references/experiment-todo-template.md`.
+
+Each TODO item should include:
+
+- the review issue it answers
+- why existing evidence is still insufficient
+- the minimum experiment or analysis needed
+- required metric(s)
+- minimal success criterion
+- whether this is:
+  - analysis of existing results
+  - new comparator baseline
+  - supplementary experiment
+  - figure / table regeneration only
+
+Do not write a vague “run more ablations” list.
+Each TODO item should be concrete enough to turn into `analysis-campaign` slices or a `baseline` recovery task.
+When extra evidence is truly needed, use the shared supplementary-experiment protocol:
+
+- recover ids / refs first if needed
+- create one `artifact.create_analysis_campaign(...)`
+- represent even one extra run as a one-slice campaign
+- record each completed slice with `artifact.record_analysis_slice(...)`
+
+Do not invent a separate review-only experiment workflow.
+
+### 6. Route the next step
+
+After the review artifacts are durable:
+
+- if the issues are mostly narrative or claim-scope fixes, route to `write`
+- if novelty / positioning is still unclear, route to `scout`
+- if a requested comparator baseline is missing, route to `baseline`
+- if new evidence is truly required, route to `analysis-campaign`
+- if the route is costly or non-obvious, record a `decision`
+
+Do not stop immediately after writing the review if the next route is already clear.
+
+## Companion skill routing
+
+Open additional skills only when the review workflow requires them:
+
+- `intake-audit`
+  - when the current draft/result/bundle state is still unclear
+- `scout`
+  - when novelty, positioning, or related-work coverage is genuinely uncertain
+- `baseline`
+  - when a missing comparator baseline blocks fair review
+- `analysis-campaign`
+  - when the review identifies concrete evidence gaps that need supplementary runs
+- `write`
+  - when the review identifies text, outline, claim-scope, or figure revisions
+- `figure-polish`
+  - when the review identifies figure/table quality as a real weakness
+- `decision`
+  - when route choice, cost, or claim downgrade is non-trivial
+
+## Artifact routing guidance
+
+Use these tools deliberately:
+
+- `artifact.record(kind='decision', ...)`
+  - review conclusion, claim downgrade recommendation, route choice, stop/go recommendation
+- `artifact.create_analysis_campaign(...)`
+  - when the experiment TODO list should become concrete follow-up slices
+- `artifact.record_analysis_slice(...)`
+  - one completed review-driven slice
+- `artifact.submit_paper_outline(mode='revise', ...)`
+  - when the review materially changes the narrative blueprint
+- `artifact.submit_paper_bundle(...)`
+  - only when the revised manuscript package is genuinely ready
+- `artifact.interact(...)`
+  - user-visible progress and review milestones
+
+## Memory discipline
+
+Stage-start requirement:
+
+- run `memory.list_recent(scope='quest', limit=5)`
+- run at least one `memory.search(...)` for:
+  - paper title
+  - main method name
+  - review or self-review
+  - key claim or strongest figure
+
+Stage-end requirement:
+
+- if the review produced a durable lesson, claim downgrade, revision rule, or experiment-gap judgment, write at least one `memory.write(...)`
+
+Useful tags include:
+
+- `stage:review`
+- `type:paper-review`
+- `type:revision-plan`
+- `type:experiment-gap`
+- `type:claim-downgrade`
+
+## Success condition
+
+`review` is successful when:
+
+- a reliable skeptical review note exists
+- the highest-risk issues are explicit
+- the next revision route is unambiguous
+- any needed experiments are captured as a concrete TODO list
+- the quest can continue into `write`, `analysis-campaign`, `baseline`, `scout`, or `finalize` without ambiguity
+
+The goal is not to sound severe.
+The goal is to make the next revision step technically clear and evidence-bound.

package/src/skills/review/references/experiment-todo-template.md

@@ -0,0 +1,29 @@
+# Review Experiment TODO Template
+
+## Follow-up experiment / analysis TODOs
+
+### TODO EXP-001
+
+- source review issue:
+- why current evidence is insufficient:
+- route type:
+  - existing-result analysis
+  - comparator baseline
+  - supplementary experiment
+  - figure / table regeneration
+- minimum task:
+- required metric(s):
+- minimal success criterion:
+- expected manuscript impact:
+- owner / next step:
+
+### TODO EXP-002
+
+- source review issue:
+- why current evidence is insufficient:
+- route type:
+- minimum task:
+- required metric(s):
+- minimal success criterion:
+- expected manuscript impact:
+- owner / next step:

package/src/skills/review/references/review-report-template.md

@@ -0,0 +1,83 @@
+# Review Report Template
+
+## Summary
+
+- paper / draft:
+- overall judgment:
+- top 3 highest-risk issues:
+
+## Strengths
+
+- 
+
+## Weaknesses
+
+- 
+
+## Key Issues
+
+### Issue 1
+
+- why it matters:
+- evidence anchor:
+- risk level:
+- likely route:
+
+### Issue 2
+
+- why it matters:
+- evidence anchor:
+- risk level:
+- likely route:
+
+## Actionable Suggestions
+
+- problem:
+- cause:
+- actionable fix:
+- acceptance criterion:
+
+## Storyline Options + Writing Outlines
+
+- current narrative weakness:
+- stronger storyline option:
+- outline change needed:
+
+## Priority Revision Plan
+
+1. 
+2. 
+3. 
+
+## Experiment Inventory & Research Experiment Plan
+
+- what existing experiments already cover:
+- what still lacks evidence:
+- which gaps are text-only rather than experiment-only:
+
+## Novelty Verification & Related-Work Matrix
+
+### Taxonomy
+
+```text
+Root
+├── Branch A
+│   └── Leaf A1
+└── Branch B
+    └── Leaf B1
+```
+
+### Comparison Matrix
+
+| Topic | This paper | Closest prior work | Overlap | Residual novelty / value |
+| --- | --- | --- | --- | --- |
+|  |  |  |  |  |
+
+## References
+
+- 
+
+## Optional Internal Score
+
+- overall score:
+- post-revision target:

package/src/skills/review/references/revision-log-template.md

@@ -0,0 +1,40 @@
+# Revision Log Template
+
+## Revision Summary
+
+- current draft state:
+- highest-priority fixes:
+- blockers:
+
+## Issue-by-issue log
+
+### Issue REV-001
+
+- source issue:
+- severity:
+- why it matters:
+- fix type:
+  - text revision
+  - literature positioning
+  - baseline recovery
+  - supplementary experiment
+  - claim downgrade
+- concrete change:
+- status:
+- blocks finalize:
+
+### Issue REV-002
+
+- source issue:
+- severity:
+- why it matters:
+- fix type:
+- concrete change:
+- status:
+- blocks finalize:
+
+## Deferred / downgraded items
+
+- item:
+- reason:
+- how the manuscript should reflect the limitation:

package/src/skills/scout/SKILL.md

@@ -12,13 +12,14 @@ Use this skill when the quest does not yet have a stable research frame.
 - Treat `artifact.interact(...)` as the main long-lived communication thread across TUI, web, and bound connectors.
 - If `artifact.interact(...)` returns queued user requirements, treat them as the highest-priority user instruction bundle before continuing scouting.
 - Immediately follow any non-empty mailbox poll with another `artifact.interact(...)` update that confirms receipt; if the request is directly answerable, answer there, otherwise say the current subtask is paused, give a short plan plus nearest report-back point, and handle that request first.
-- Emit `artifact.interact(kind='progress', reply_mode='threaded', ...)` only at real checkpoints, but poll more actively during live work: usually every 3 to 8 tool calls, before another multi-step batch, and before or after long-running `bash_exec` work. Keep updates high-signal and never filler.
-- Each progress update must state completed scouting work, the durable output touched, and the immediate next framing step.
-- Message templates are references only. Adapt to the actual context and vary wording so updates feel respectful, human, and non-robotic.
+- Emit `artifact.interact(kind='progress', reply_mode='threaded', ...)` only when there is real user-visible progress: the first meaningful signal of long work, a meaningful checkpoint, or an occasional keepalive during truly long work. Do not update by tool-call cadence.
+- Keep progress updates chat-like and easy to understand: say what changed, what it means, and what happens next.
+- Default to plain-language summaries. Do not mention file paths, artifact ids, branch/worktree ids, session ids, raw commands, or raw logs unless the user asks or needs them to act.
+- Message templates are references only. Adapt to the actual context and vary wording so updates feel natural and non-robotic.
 - Use `reply_mode='blocking'` only for real user decisions that cannot be resolved from local evidence.
-- For any blocking decision request, provide 1 to 3 concrete options, put the recommended option first, explain each option's actual content plus pros and cons, wait up to 1 day when feasible, then choose the best option yourself and notify the user of the chosen option if the timeout expires.
+- For any blocking decision request, provide 1 to 3 concrete options, put the recommended option first, explain each option's actual content plus pros and cons, and wait up to 1 day when feasible. If the blocker is a missing external credential or secret that only the user can provide, keep the quest waiting, ask the user to supply it or choose an alternative, and do not self-resolve; if resumed without that credential and no other work is possible, a long low-frequency wait such as `bash_exec(command='sleep 3600', mode='await', timeout_seconds=3700)` is acceptable. Otherwise choose the best option yourself and notify the user of the chosen option if the timeout expires.
 - If a threaded user reply arrives, interpret it relative to the latest scout progress update before assuming the task changed completely.
-- When scouting actually resolves the framing ambiguity, locks the evaluation contract, or makes the next anchor obvious, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that names the chosen next anchor and the key files or artifacts behind it.
+- When scouting actually resolves the framing ambiguity, locks the evaluation contract, or makes the next anchor obvious, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what is now clear, why it matters, and which stage should come next.
 
 ## Stage purpose
 

package/src/skills/write/SKILL.md

@@ -22,11 +22,12 @@ This skill intentionally absorbs the strongest old DeepScientist writing discipl
 - Treat `artifact.interact(...)` as the main long-lived communication thread across TUI, web, and bound connectors.
 - If `artifact.interact(...)` returns queued user requirements, treat them as the highest-priority user instruction bundle before continuing drafting or revision.
 - Immediately follow any non-empty mailbox poll with another `artifact.interact(...)` update that confirms receipt; if the request is directly answerable, answer there, otherwise say the current subtask is paused, give a short plan plus nearest report-back point, and handle that request first.
-- Emit `artifact.interact(kind='progress', reply_mode='threaded', ...)` only at real checkpoints, but poll more actively during live work: usually every 3 to 8 tool calls, before another multi-step batch, and before or after long-running `bash_exec` work. Keep updates high-signal and never filler.
+- Emit `artifact.interact(kind='progress', reply_mode='threaded', ...)` only when there is real user-visible progress: the first meaningful signal of long work, a meaningful checkpoint, or an occasional keepalive during truly long work. Do not update by tool-call cadence.
 - Prefer `bash_exec` for durable document-build commands such as LaTeX compilation, figure regeneration, and scripted export steps so logs remain quest-local and reviewable.
-- Each progress update must state completed writing work, the durable output touched, and the immediate next drafting or review step.
+- Keep progress updates chat-like and easy to understand: say what changed, what it means, and what happens next.
+- Default to plain-language summaries. Do not mention file paths, artifact ids, branch/worktree ids, session ids, raw commands, or raw logs unless the user asks or needs them to act.
 - Keep ordinary subtask completions concise. When a paper/draft milestone is actually completed, upgrade to a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` report instead of another short progress update.
-- That richer writing-stage milestone report should normally cover: which draft/section/outline milestone finished, the durable files produced or revised, the strongest claims now supported by evidence, the remaining evidence or writing gaps, and the exact recommended next revision or route decision.
+- That richer writing-stage milestone report should normally cover: which draft, section, or outline milestone finished, what is now supportable, what is still missing, and the exact recommended next revision or route decision.
 - That richer milestone report is still normally non-blocking. If the next writing or return-to-experiment step is already clear, continue automatically after reporting instead of pausing by default.
 - If the active communication surface is QQ, keep writing milestones text-first unless a final paper PDF or one clearly useful summary artifact already exists.
 - Treat connector-facing report charts separately from paper-facing figures; do not auto-send draft paper figures to QQ.
@@ -55,7 +56,7 @@ This skill intentionally absorbs the strongest old DeepScientist writing discipl
 - If the runtime starts an auto-continue turn with no new user message, keep drafting or verifying from the durable state and active requirements instead of replaying the previous user turn.
 - Message templates are references only. Adapt to the actual context and vary wording so updates feel respectful, human, and non-robotic.
 - Use `reply_mode='blocking'` only for real user decisions that cannot be resolved from local evidence.
-- For any blocking decision request, provide 1 to 3 concrete options, put the recommended option first, explain each option's actual content plus pros and cons, wait up to 1 day when feasible, then choose the best option yourself and notify the user of the chosen option if the timeout expires.
+- For any blocking decision request, provide 1 to 3 concrete options, put the recommended option first, explain each option's actual content plus pros and cons, and wait up to 1 day when feasible. If the blocker is a missing external credential or secret that only the user can provide, keep the quest waiting, ask the user to supply it or choose an alternative, and do not self-resolve; if resumed without that credential and no other work is possible, a long low-frequency wait such as `bash_exec(command='sleep 3600', mode='await', timeout_seconds=3700)` is acceptable. Otherwise choose the best option yourself and notify the user of the chosen option if the timeout expires.
 - If a threaded user reply arrives, interpret it relative to the latest writing progress update before assuming the task changed completely.
 - Use milestone updates deliberately when outline selection, claim downgrades, proofing completion, bundle readiness, or route-back-to-experiment decisions become durably true.
 
@@ -604,6 +605,9 @@ Run that review with an adversarial mindset:
 - prefer deleting or downgrading an attractive but weak claim over defending it with rhetoric
 - if a neutral outsider could not trace a claim back to concrete evidence, treat that as a writing failure, not as a presentation problem
 
+When the draft is substantial enough to judge rather than merely sketch, open `review/SKILL.md` for an independent skeptical audit before you call the paper task done.
+Use that review pass to decide whether the next route is further writing, a claim downgrade, a literature audit, a baseline recovery step, or a reviewer-linked follow-up experiment campaign.
+
 ### Phase 7.5. Revision loop
 
 Do not stop after a single self-review pass.

package/src/tui/dist/components/WelcomePanel.js

@@ -4,42 +4,13 @@ import Gradient from 'ink-gradient';
 import stringWidth from 'string-width';
 import { Logo } from './Logo.js';
 import { theme } from '../semantic-colors.js';
-import { robotAsciiData } from './AsciiArt.js';
 import { useTerminalSize } from '../hooks/useTerminalSize.js';
 // Colors matching AsciiArt
 const COLORS = {
     blue: '#4796E4',
     red: '#F38BA8',
     gradient: ['#9B59B6', '#8E44AD', '#C471ED', '#F64F9C'],
-};
-const SegmentedLine = ({ line, segments }) => {
-    const parts = [];
-    const sortedSegments = [...segments].sort((a, b) => a.start - b.start);
-    let lastEnd = 0;
-    sortedSegments.forEach((segment, idx) => {
-        if (segment.start > lastEnd) {
-            parts.push(React.createElement(Text, { key: `gap-${idx}` }, line.slice(lastEnd, segment.start)));
-        }
-        const text = line.slice(segment.start, segment.end);
-        if (segment.type === 'gradient') {
-            parts.push(React.createElement(Gradient, { key: `seg-${idx}`, colors: COLORS.gradient },
-                React.createElement(Text, null, text)));
-        }
-        else if (segment.type === 'blue') {
-            parts.push(React.createElement(Text, { key: `seg-${idx}`, color: COLORS.blue }, text));
-        }
-        else if (segment.type === 'red') {
-            parts.push(React.createElement(Text, { key: `seg-${idx}`, color: COLORS.red }, text));
-        }
-        else {
-            parts.push(React.createElement(Text, { key: `seg-${idx}` }, text));
-        }
-        lastEnd = segment.end;
-    });
-    if (lastEnd < line.length) {
-        parts.push(React.createElement(Text, { key: "tail" }, line.slice(lastEnd)));
-    }
-    return React.createElement(Text, null, parts);
+    gold: '#B69B4A',
 };
 const clipText = (value, maxWidth) => {
     const safeWidth = Math.max(4, maxWidth);
@@ -75,10 +46,6 @@ export const WelcomePanel = ({ quests, browseQuestId, connectors, baseUrl, conne
     const compactConnectorSummary = connectors.length > 0
         ? `${connectors.length} connectors configured`
         : 'No connectors configured';
-    const robotLines = robotAsciiData.lines;
-    const robotSegments = robotAsciiData.segments;
-    const showRobot = columns >= 100;
-    const showHeaderSideBySide = columns >= 140;
     const showApiLine = columns >= 120;
     const resolvedBaseUrl = (() => {
         try {
@@ -105,7 +72,6 @@ export const WelcomePanel = ({ quests, browseQuestId, connectors, baseUrl, conne
         { label: '', value: 'Research operating system', style: 'title' },
         { label: 'Mode', value: selectedQuest ? 'quest mode' : 'request mode', style: 'normal' },
         { label: 'Server', value: connectionText, style: 'connection' },
-        { label: 'Frontend', value: frontendUrl, style: 'normal' },
         ...(showApiLine ? [{ label: 'API', value: apiUrl, style: 'normal' }] : []),
         {
             label: 'Quests',
@@ -126,17 +92,25 @@ export const WelcomePanel = ({ quests, browseQuestId, connectors, baseUrl, conne
         ? clipText(`${selectedQuest.status} · ${selectedQuest.active_anchor} · ${selectedQuest.branch || 'main'}`, columns - 2)
         : null;
     const emptyQuestLine = clipText('No quest selected yet. Use /new <goal> to create one or /use <quest_id> to bind one.', columns - 2);
+    const urlBannerText = clipText(frontendUrl, Math.max(24, columns - 6));
+    const urlHint = columns >= 108
+        ? 'Press Ctrl+O to open the web workspace if auto-open is unavailable.'
+        : 'Ctrl+O opens the web workspace.';
     return (React.createElement(Box, { flexDirection: "column", marginBottom: 1 },
-        React.createElement(Box, { flexDirection: showHeaderSideBySide ? 'row' : 'column' },
-            showRobot ? (React.createElement(Box, { flexDirection: "column", marginRight: showHeaderSideBySide ? 2 : 0, marginBottom: showHeaderSideBySide ? 0 : 1 }, robotLines.map((line, idx) => (React.createElement(SegmentedLine, { key: `robot-${idx}`, line: line, segments: robotSegments[idx] || [] }))))) : null,
-            React.createElement(Box, { flexDirection: "column", justifyContent: "center" }, infoLines.map((info, idx) => (React.createElement(Box, { key: idx }, info.style === 'title' ? (React.createElement(Gradient, { colors: COLORS.gradient },
-                React.createElement(Text, { bold: true }, info.value))) : (React.createElement(React.Fragment, null,
-                info.label && (React.createElement(Text, { color: theme.text.secondary },
-                    info.label,
-                    ": ")),
-                React.createElement(Text, { color: info.style === 'connection' ? connectionColor : theme.text.primary }, info.value)))))))),
+        React.createElement(Box, { flexDirection: "column" }, infoLines.map((info, idx) => (React.createElement(Box, { key: idx }, info.style === 'title' ? (React.createElement(Gradient, { colors: COLORS.gradient },
+            React.createElement(Text, { bold: true }, info.value))) : (React.createElement(React.Fragment, null,
+            info.label && (React.createElement(Text, { color: theme.text.secondary },
+                info.label,
+                ": ")),
+            React.createElement(Text, { color: info.style === 'connection' ? connectionColor : theme.text.primary }, info.value))))))),
         React.createElement(Box, { marginTop: 1 },
             React.createElement(Logo, null)),
+        React.createElement(Box, { marginTop: 1, width: columns, justifyContent: "center" },
+            React.createElement(Text, { color: COLORS.gold }, "Web Workspace")),
+        React.createElement(Box, { width: columns, justifyContent: "center" },
+            React.createElement(Text, { bold: true, color: COLORS.blue }, urlBannerText)),
+        React.createElement(Box, { width: columns, justifyContent: "center" },
+            React.createElement(Text, { color: theme.text.secondary }, clipText(urlHint, Math.max(20, columns - 4)))),
         React.createElement(Box, { marginTop: 1 },
             React.createElement(Text, { color: theme.text.secondary }, commandLine)),
         React.createElement(Box, { marginTop: 1, flexDirection: "column" },

package/src/tui/dist/components/messages/BashExecOperationMessage.js

@@ -9,6 +9,7 @@ const MAX_VISIBLE_LOG_LINES = 18;
 const BASH_CARRIAGE_RETURN_PREFIX = '__DS_BASH_CR__';
 const BASH_PROGRESS_PREFIX = '__DS_PROGRESS__';
 const BASH_STATUS_MARKER_PREFIX = '__DS_BASH_STATUS__';
+const EMPTY_RESULT_PAYLOAD = Object.freeze({});
 const stripAnsi = (value) => value.replace(/\u001b\[[0-9;?]*[ -/]*[@-~]/g, '').replace(/\u001b[@-_]/g, '');
 const parseJsonRecord = (value) => {
     const text = String(value || '').trim();
@@ -216,7 +217,7 @@ function buildListLines(payload) {
 export const BashExecOperationMessage = ({ label, content, toolName, toolCallId, status, args, output, mcpServer, mcpTool, metadata, width = 80, baseUrl, questId, live = false, }) => {
     const argsPayload = useMemo(() => parseJsonRecord(args), [args]);
     const outputPayload = useMemo(() => parseJsonRecord(output), [output]);
-    const resultPayload = outputPayload ?? {};
+    const resultPayload = outputPayload ?? EMPTY_RESULT_PAYLOAD;
     const mode = String(argsPayload?.mode || metadata?.mode || 'detach').trim().toLowerCase() || 'detach';
     const command = String(argsPayload?.command || metadata?.command || resultPayload.command || '').trim();
     const workdir = normalizeWorkdir(typeof argsPayload?.workdir === 'string'
@@ -244,7 +245,7 @@ export const BashExecOperationMessage = ({ label, content, toolName, toolCallId,
     const initialProgress = resultPayload.last_progress && typeof resultPayload.last_progress === 'object'
         ? resultPayload.last_progress
         : null;
-    const listLines = useMemo(() => buildListLines(resultPayload), [resultPayload]);
+    const listLines = useMemo(() => buildListLines(resultPayload), [outputPayload]);
     const [bashId, setBashId] = useState(initialBashId);
     const [sessionStatus, setSessionStatus] = useState(initialStatus);
     const [exitCode, setExitCode] = useState(typeof resultPayload.exit_code === 'number' ? resultPayload.exit_code : null);

package/src/tui/package.json

@@ -1,6 +1,6 @@
 {
   "name": "deepscientist-tui",
-  "version": "1.5.0",
+  "version": "1.5.2",
   "private": true,
   "type": "module",
   "main": "dist/index.js",