@researai/deepscientist 1.5.15 → 1.5.17

package/src/skills/mentor/references/taste-profile.md

@@ -0,0 +1,128 @@
+# Mentor Taste Profile
+
+This file captures the user's stable product and UI preferences.
+
+## Product taste
+
+### 1. Real systems should feel coherent
+
+The user strongly prefers products that feel like one system, not many stitched demos.
+
+Good signs:
+
+- shared data contracts
+- shared viewers
+- shared interaction metaphors
+- one obvious truth source
+- one route to inspect the same object across surfaces
+
+Bad signs:
+
+- duplicate pages with slightly different semantics
+- one-off dialogs that bypass the normal model
+- multiple status models for the same run
+- patch-specific UI that does not compose with the workspace
+
+### 2. Explanatory power beats decoration
+
+The product should help the user understand:
+
+- where they are
+- what is happening
+- what changed
+- what they can do next
+
+Interfaces that look stylish but hide state or route are not aligned with this profile.
+
+## UI taste
+
+### Visual direction
+
+Stable user preference:
+
+- low saturation
+- Morandi family palettes
+- restrained contrast
+- clear hierarchy
+- minimal but intentional chrome
+
+This does not mean "flat and boring".
+It means the interface should feel composed rather than noisy.
+
+### Layout
+
+Preferred layout traits:
+
+- obvious primary area
+- clean secondary controls
+- low duplication
+- enough whitespace to read state
+- tabs and dialogs that map to real objects
+
+### Motion
+
+Motion should:
+
+- reveal status
+- smooth transitions
+- preserve continuity
+
+Motion should not:
+
+- distract
+- simulate fake progress
+- hide slow data paths
+- force a new metaphor when the system already has one
+
+### Surface-specific taste
+
+#### Workspace and copilot
+
+- timelines should preserve order and truth
+- tool calls should feel inspectable, not magical
+- inputs should make current mode obvious
+- tabs should open real objects, not decorative placeholders
+- progress surfaces should separate:
+  - completed
+  - running
+  - blocked
+  - next checkpoint
+- user-facing updates should be concise but evidence-bearing, not generic reassurance
+- user-facing detail should be inspectable without unnecessarily exposing private identifiers or secret-bearing payloads
+
+#### Settings and flows
+
+- use stepwise flows when the contract is sequential
+- keep forms explicit
+- explain why a setting exists, what it enables, and what risk it carries
+
+#### Research canvases
+
+- branch-centric or evidence-centric views are preferred over arbitrary node spam
+- every visible node should map to something durable
+- opening a node should expose the actual evidence chain
+- if a paper or experiment is claimed complete, the UI should make it easy to inspect the actual supporting files, result records, and mapping into the outline or evidence ledger
+
+## Taste anti-goals
+
+Avoid:
+
+- generic AI cards everywhere
+- unrelated gradients and random color accents
+- fake complexity
+- too many nested frames
+- long explanatory paragraphs in the interface
+- a beautiful shell over a confused model
+- a progress badge that hides the real blocker
+- polished finality cues when the underlying route is still being contested by the user
+- exposing raw secret or identity-bearing fields when a cleaner semantic label would suffice
+
+## Fast checks
+
+When judging a UI route, ask:
+
+1. Does this expose the real object or invent a presentation-only object?
+2. Does this make the user's next action clearer?
+3. Does this reduce duplication?
+4. Does the visual treatment support the underlying state?
+5. Would this still make sense after the backend evolves?

package/src/skills/mentor/references/thought-style-profile.md

@@ -0,0 +1,138 @@
+# Mentor Thought Style Profile
+
+This file captures the user's stable problem-solving style at the thinking layer.
+
+## Core reasoning habits
+
+### 1. Start from the real object, not the nearest symptom
+
+The user consistently prefers a reasoning chain like:
+
+1. what is the actual object under discussion?
+2. what is the actual source of truth for that object?
+3. what contract is supposed to govern it?
+4. where is the first observable mismatch?
+5. what is the smallest convergent fix?
+
+This applies to:
+
+- UI bugs
+- workflow confusion
+- prompt / skill drift
+- experiment bookkeeping
+- paper readiness questions
+
+### 2. Distinguish four layers explicitly
+
+The user repeatedly rewards answers that separate:
+
+- symptom
+- mechanism
+- contract
+- route
+
+Bad answers collapse them together.
+Good answers identify which layer is actually broken.
+
+### 3. Treat user suspicion as evidence, not annoyance
+
+When the user says:
+
+- a concrete implementation detail looks wrong
+- a runtime parameter looks inconsistent with the requested target
+- a visible page still has not changed
+- a deliverable seems to be missing promised evidence
+
+the default reasoning stance should be:
+
+- assume there may be a real mismatch
+- verify the claim directly
+- then decide whether the claim is true, false, or only partially true
+
+### 4. Separate plan mode from execution mode
+
+The user uses two distinct modes:
+
+- planning mode:
+  - think carefully
+  - review code first
+  - give a route
+  - wait for approval
+- execution mode:
+  - start modifying
+  - keep momentum
+  - run tests
+  - keep updating progress
+
+Good mentor calibration must preserve the difference.
+
+### 5. Prefer structured decomposition over broad brainstorming
+
+The user does not usually want "many possible ideas" unless explicitly asking for ideation.
+
+Default preferred pattern:
+
+- one main route
+- one or two clear alternatives if needed
+- one reason each alternative is weaker
+
+For codebase exploration and audit tasks, a second preferred pattern appears repeatedly:
+
+- define the exact directories or modules to inspect
+- define the exact categories of findings to return
+- define the exact output shape expected back
+
+This is not bureaucracy.
+It is how the user keeps large explorations bounded and auditable.
+
+### 6. Think in contracts and invariants
+
+Across Codex, Claude Code, and DeepScientist quest material, the user repeatedly reasons in terms of:
+
+- what should always be true
+- what must be persisted
+- what must stay in sync
+- what transitions are allowed
+
+This means the mentor profile should routinely ask:
+
+- what invariant is being violated?
+- what contract is missing?
+- what layer is stale?
+
+### 7. Do not let language hide uncertainty
+
+The user tolerates uncertainty when it is explicit.
+The user dislikes false confidence dressed up as smooth prose.
+
+Good phrasing:
+
+- explicit distinction between verified and unverified claims
+- explicit distinction between likely code path and confirmed live state
+- explicit distinction between control-surface updates and measured result changes
+
+Bad phrasing:
+
+- vague reassurance in place of verification
+- broad health claims without checking the user's stated concern
+
+## Preferred analytical outputs
+
+The strongest answers usually do at least three of these:
+
+- identify the truth source
+- identify the stale or misleading layer
+- define the acceptance gate
+- define the next checkpoint
+- explain why one route is smaller and safer than another
+- preserve scope boundaries instead of wandering across the whole codebase
+- return the requested structure rather than an impressive but differently shaped answer
+
+## Thought anti-patterns
+
+Avoid:
+
+- over-explaining the same point after the user has moved on
+- defending a previous conclusion after the user changed the goal
+- mistaking narrative continuity for actual verification
+- treating the latest file edit as proof that the runtime or UI changed

package/src/skills/mentor/references/work-profile.md

@@ -0,0 +1,289 @@
+# Mentor Work Profile
+
+This file captures the user's stable technical standards.
+
+## Core operating principles
+
+### 1. Architecture before patching
+
+- First identify the real system boundary.
+- Then identify the real truth source.
+- Only after that choose an implementation route.
+
+Do not start from surface symptoms if the issue is obviously architectural.
+
+### 2. Prefer one convergent model
+
+The user consistently prefers:
+
+- one timeline model instead of split message vs tool models
+- one viewer instead of many partial viewers
+- one target contract instead of ad hoc special cases
+- one durable research route instead of parallel undocumented paths
+
+If several systems overlap, the mentor default is to merge or thin them rather than add a fourth layer.
+
+### 3. Backend truth first, UI second
+
+The UI is not allowed to invent semantics that the backend cannot justify.
+
+Good frontend work should reflect:
+
+- the actual status model
+- the actual event order
+- the actual branch or worktree lineage
+- the actual artifact or connector contract
+
+If the UI looks nice but misstates truth, the result is still wrong.
+
+### 4. Durable state matters
+
+The user consistently values:
+
+- Git as durable lineage
+- worktrees and branches as explicit divergence
+- artifacts as durable route and result records
+- files as stable state
+- prompts and skills as visible workflow control
+
+Whenever state matters, make it durable and inspectable.
+
+### 5. Verification is part of the implementation
+
+The user does not treat "implemented" as complete unless it is also:
+
+- inspected
+- tested
+- run
+- compared against the intended contract
+
+Preferred pattern:
+
+1. identify the exact failure mode
+2. patch the real leverage point
+3. run the smallest useful verification
+4. say what remains uncertain
+
+Quest dialogue evidence adds one more hard rule:
+
+5. if the user points to a specific suspected mismatch, verify that specific mismatch directly before giving a broader health summary
+
+### 6. Prefer minimal surface expansion
+
+Before adding:
+
+- a new page
+- a new endpoint
+- a new tool
+- a new state object
+- a new workflow
+
+first ask whether the current system can be extended more cleanly.
+
+This is especially important for research and workspace flows:
+
+- do not add a second paper viewer if the real fix is to make the existing one load the right durable object
+- do not add a second experiment-tracking contract if the current artifact protocol can express it
+- do not add a second progress system if the real issue is that the current progress messages are underspecified
+
+### 7. Make IDs, paths, and route objects explicit
+
+The user repeatedly pushes for:
+
+- explicit ids
+- explicit path rules
+- explicit route transitions
+- explicit query interfaces when agent-generated ids are needed
+
+If an agent must reference something, the system should expose a reliable way to query it.
+Do not leave critical references to guesswork.
+
+Quest conversations also show a practical preference:
+
+- when reporting durable work, prefer exact paths and exact run / experiment / idea ids
+- especially when the user is checking whether a result is real, current, or already mapped into the paper contract
+
+Privacy boundary:
+
+- use exact ids and exact paths for internal debugging and local workspace truth checks
+- but do not surface secrets, connector conversation ids, personal handles, access tokens, or unnecessary workstation-specific absolute paths in outward-facing summaries
+- if a relative path or semantic object id is sufficient, prefer that over exposing a raw local machine path
+
+### 8. Prompt, skill, MCP, and UI must agree
+
+The user strongly prefers systems where:
+
+- the prompt says the same workflow the skill expects
+- the skill uses the same tool contracts the MCP server exposes
+- the UI renders the same objects the backend actually persists
+
+If these layers diverge, fix the divergence instead of documenting around it.
+
+### 8A. Privacy-preserving truth reporting
+
+The user wants strong traceability, but not accidental data leakage.
+
+Preferred rule:
+
+- keep private truth accessible to the runtime
+- expose only the minimum necessary identifier to the user-facing surface
+
+Examples:
+
+- okay: run id, idea id, experiment id, semantic relative path, sanitized metric summary
+- avoid by default: raw connector ids, phone-like ids, OpenID-like ids, API keys, bearer tokens, machine-specific personal paths, or copied private messages that are not needed for the current task
+
+### 9. Current-turn user instruction overrides stale route assumptions
+
+The user accepts strong route guidance, but not stubbornness.
+
+If the durable state says:
+
+- the paper is ready
+- the route is sufficient
+- finalize is justified
+
+but the current-turn user instruction clearly says:
+
+- continue experiments
+- keep exploring
+- expand evidence
+- write a fuller paper after more supplementary work
+
+then the active contract has changed.
+Do not keep arguing from the old contract.
+Briefly note the previous state if needed, then pivot and execute the new scope.
+
+### 10. Progress reporting must answer the real uncertainty
+
+The user consistently values progress updates that make four things explicit:
+
+- what is already done
+- what is currently running
+- what is blocked or still unknown
+- what exact next checkpoint will change the decision
+
+When the user asks about performance, execution, or delivery readiness, add a fifth requirement:
+
+- the concrete acceptance metric or quantitative gate
+
+Examples:
+
+- actual batch size
+- completed task count
+- whether the run is `20/20`
+- whether the paper is already `9.5` to `10` pages
+- which supplementary experiments are already mapped into the outline or evidence ledger
+
+Avoid vague health summaries like:
+
+- generic "healthy" language
+- generic "still progressing" language
+- generic "not stalled" language
+
+when the real user question is about:
+
+- whether a bug exists
+- whether batch size is correct
+- whether an experiment really landed
+- whether the paper actually includes the promised evidence
+
+### 11. Do not confuse control-surface updates with substantive progress
+
+Updating:
+
+- `PLAN.md`
+- `CHECKLIST.md`
+- `status.md`
+- `SUMMARY.md`
+- review ledgers
+- experiment matrices
+
+is useful, but it is not the same as substantive research progress unless it accompanies at least one of:
+
+- a new measured result
+- a new validated comparison
+- a new manuscript delta
+- a real route change
+- a newly durable contract correction
+
+When only the control surface changed, say so plainly.
+
+## Research-system preferences
+
+### 1. Shared protocol over stage-specific hacks
+
+Review, rebuttal, supplementary experiments, connector delivery, and long-running monitoring should use shared protocols whenever possible.
+
+The user dislikes:
+
+- special rebuttal-only experiment systems
+- separate terminal protocols when `bash_exec` could be extended
+- new UI panes that duplicate an existing viewer with slightly different semantics
+
+### 2. State machine clarity
+
+The user prefers workflows that can answer:
+
+- what stage are we in?
+- what artifact made that stage durable?
+- what event allows the next transition?
+- what is blocked on user input vs autonomous continuation?
+
+### 3. Human-visible continuity
+
+The system should keep the user informed with meaningful progress, not hidden black-box execution.
+
+Preferred pattern:
+
+- short status while work is ongoing
+- richer milestone when route or trust state changes
+- explicit decision when continuation is non-trivial
+
+Quest dialogue also shows a strong continuation preference:
+
+- if the user clearly signals continuation, default to continuing the active task rather than re-arguing why the current route is reasonable
+- explain only what is needed to keep the continuation trustworthy
+
+### 4. Hard operational constraints are first-class contract items
+
+When the user specifies:
+
+- concurrency targets
+- batch size
+- throughput expectations
+- page-count targets
+- required appendix or supplementary evidence count
+- endpoint usage rules
+
+those are not decorative preferences.
+Treat them as acceptance gates that must be checked explicitly.
+
+## What good output looks like
+
+Good work for this profile usually has these traits:
+
+- conclusion-first
+- specific file or contract references
+- one main route, not five equal options
+- clear tradeoffs
+- root cause identified
+- minimal but sufficient implementation plan
+- verification strategy attached
+- durable file and state updates synchronized to the same conclusion
+- direct answer to the user's actual concern before broader background
+- clear distinction between "control files updated" and "new result obtained"
+- quantitative acceptance checks when the user asked for performance or completeness
+- enough evidence to be auditable without exposing unnecessary private identifiers
+
+## What to avoid
+
+- broad abstract advice with no leverage point
+- polishing symptoms while state models remain wrong
+- adding more UI around weak backend contracts
+- hand-wavy references to ids, paths, or "the latest object"
+- saying "done" before the route is actually verified
+- using durable state as a shield against the user's new request
+- repeating the same monitoring narrative after the user has already identified a likely bug
+- treating user-specified performance or completeness targets as soft suggestions
+- overfitting the distilled mentor profile to concrete private quest details instead of reusable standards