mirror of
https://github.com/lobehub/lobehub
synced 2026-04-21 09:37:28 +00:00
resolve merge conflicts
This commit is contained in:
Arvin Xu
parent
a0303b7c18
commit
038070285a
7 changed files with 6 additions and 301 deletions
|
|
@ -5,7 +5,6 @@ description: "Version release workflow. Use when the user mentions 'release', 'h
|
|||
|
||||
# Version Release Workflow
|
||||
|
||||
<<<<<<< HEAD
|
||||
## Scope Boundary (Important)
|
||||
|
||||
This skill is only for:
|
||||
|
|
@ -17,19 +16,12 @@ This skill is only for:
|
|||
This skill is **not** for writing `docs/changelog/*.mdx`.\
|
||||
If the user asks for website changelog pages, load `../docs-changelog/SKILL.md`.
|
||||
|
||||
=======
|
||||
>>>>>>> origin/main
|
||||
## Mandatory Companion Skill
|
||||
|
||||
For every `/version-release` execution, you MUST load and apply:
|
||||
|
||||
- `../microcopy/SKILL.md`
|
||||
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
Changelog style guidance is now fully embedded in this skill. Keep release facts unchanged, and only improve structure, readability, and tone.
|
||||
|
||||
>>>>>>> origin/main
|
||||
## Overview
|
||||
|
||||
The primary development branch is **canary**. All day-to-day development happens on canary. When releasing, canary is merged into main. After merge, `auto-tag-release.yml` automatically handles tagging, version bumping, creating a GitHub Release, and syncing back to the canary branch.
|
||||
|
|
@ -176,7 +168,6 @@ Do not use this as `docs/changelog` page guidance.
|
|||
|
||||
This release-note style is:
|
||||
|
||||
<<<<<<< HEAD
|
||||
1. **Data-backed at the top** (date, range, key metrics)
|
||||
2. **Narrative first, then structured detail**
|
||||
3. **Deep but scannable** (clear sectioning + compact bullets)
|
||||
|
|
@ -325,189 +316,3 @@ Use `---` separators between major blocks for long releases.
|
|||
- [ ] Security and reliability updates are explicitly surfaced (when present)
|
||||
- [ ] Contributor credits and compare range are included
|
||||
- [ ] All numbers and claims are verifiable
|
||||
=======
|
||||
### Mandatory Inputs Before Writing
|
||||
|
||||
1. Release diff context (`git log main..canary` and/or `git diff main...canary --stat`)
|
||||
2. Existing release template constraints (title, credits, trigger rules)
|
||||
3. `../microcopy/SKILL.md` terminology constraints
|
||||
|
||||
### Output Constraints (Hard Rules)
|
||||
|
||||
1. Keep all factual claims accurate to merged changes.
|
||||
2. Do not invent numbers, scope, timelines, or availability tiers.
|
||||
3. Keep release title and trigger-sensitive format unchanged.
|
||||
4. Keep `Credits` section intact (format required by project conventions).
|
||||
5. Prefer fewer headings and more natural narrative paragraphs.
|
||||
6. EN/ZH versions must cover the same facts in the same order.
|
||||
7. Prefer storytelling over feature enumeration.
|
||||
8. Avoid `Key Updates` sections that are only bullet dumps unless explicitly requested.
|
||||
|
||||
### Editorial Voice (Notion/Linear-Inspired)
|
||||
|
||||
Target a changelog voice that is calm, confident, and human:
|
||||
|
||||
- Start from user reality, not internal implementation.
|
||||
- Explain why this change matters before listing mechanics.
|
||||
- Keep tone practical and grounded, but allow a little product warmth.
|
||||
- Favor concrete workflow examples over abstract claims.
|
||||
- Write like an update from a thoughtful product team, not a marketing launch page.
|
||||
|
||||
### Writing Model (3-Pass Rewrite)
|
||||
|
||||
#### Pass 1: Remove AI Vocabulary and Filler
|
||||
|
||||
- Replace inflated words with simple alternatives.
|
||||
- Remove transition padding like "furthermore", "notably", "it is worth noting that".
|
||||
- Cut generic importance inflation ("pivotal", "testament", "game-changer").
|
||||
- Prefer direct verbs like `run`, `customize`, `manage`, `capture`, `improve`, `fix`.
|
||||
|
||||
#### Pass 2: Break AI Sentence Patterns
|
||||
|
||||
Avoid these structures:
|
||||
|
||||
- Parallel negation: "Not X, but Y"
|
||||
- Tricolon overload: "A, B, and C" used repeatedly
|
||||
- Rhetorical Q + answer: "What does this mean? It means..."
|
||||
- Dramatic reveal openers: "Here's the thing", "The result?"
|
||||
- Mirror symmetry in consecutive lines
|
||||
- Overuse of em dashes
|
||||
- Every paragraph ending in tidy "lesson learned" phrasing
|
||||
|
||||
#### Pass 3: Add Human Product Texture
|
||||
|
||||
- Lead with user-visible outcome, then explain mechanism.
|
||||
- Mix sentence lengths naturally.
|
||||
- Prefer straightforward phrasing over polished-but-empty language.
|
||||
- Keep confidence, but avoid launch-ad hype.
|
||||
- Write like a product team update, not a marketing page.
|
||||
|
||||
### Recommended Structure Blueprint
|
||||
|
||||
Use this shape unless the user asks otherwise:
|
||||
|
||||
1. `# 🚀 release: ...`
|
||||
2. One opening paragraph (2-4 sentences) that explains overall user impact.
|
||||
3. 2-4 narrative capability blocks (short headings optional):
|
||||
- each block = user value + key capability
|
||||
4. `Improvements and fixes` / `体验优化与修复` with concise bullets
|
||||
5. `Credits` with required mention format
|
||||
|
||||
### Length and Reading Density (Important)
|
||||
|
||||
Avoid overly short release notes when the diff is substantial.
|
||||
|
||||
- Weekly release PR body:
|
||||
- Usually target 350-700 English words (or equivalent Chinese length)
|
||||
- Keep 2-4 narrative sections, each with at least one real paragraph
|
||||
- Minor release PR body:
|
||||
- Usually target 500-1000 English words (or equivalent Chinese length)
|
||||
- Allow richer context and more concrete usage scenarios
|
||||
- DB migration release PR body:
|
||||
- Keep concise, but still include context + impact + operator notes
|
||||
- If there are many commits, increase narrative depth before adding more bullets.
|
||||
- If there are few commits, stay concise and do not pad content.
|
||||
|
||||
### Storytelling Contract (Major Capabilities)
|
||||
|
||||
For each major capability, write in this order:
|
||||
|
||||
1. Prior context/problem (briefly)
|
||||
2. What changed in this release
|
||||
3. Practical impact on user workflow
|
||||
|
||||
Do not collapse major capability sections into one-line bullets.
|
||||
|
||||
### Section Anatomy (Preferred)
|
||||
|
||||
Each major section should follow this internal rhythm:
|
||||
|
||||
1. Lead sentence: what changed and who benefits.
|
||||
2. Context sentence: what was painful, slow, or fragmented before.
|
||||
3. Mechanism paragraph: how the new behavior works in practice.
|
||||
4. Optional utility list (`Use X to:`) for actionable workflows.
|
||||
5. Optional availability closer when plan/platform constraints matter.
|
||||
|
||||
This pattern increases readability and makes changelogs more enjoyable to read without sacrificing precision.
|
||||
|
||||
### Section and Heading Heuristics
|
||||
|
||||
- Keep heading count low (typically 3-5).
|
||||
- Weekly release PR body target:
|
||||
- 1 opening paragraph
|
||||
- 2-4 major narrative sections
|
||||
- 1 improvements/fixes section
|
||||
- 1 credits section
|
||||
- Never produce heading-per-bullet layout.
|
||||
- If a section has 4+ bullets, convert into 2-3 short narrative paragraphs when possible.
|
||||
|
||||
### Linear-Style Block Pattern
|
||||
|
||||
Use this pattern when writing major sections:
|
||||
|
||||
```md
|
||||
## <Capability name>
|
||||
|
||||
<One sentence: what users can do now and why it matters.>
|
||||
|
||||
<One short paragraph: how this works in practice, in plain language.>
|
||||
|
||||
<Optional list for workflows>
|
||||
Use <feature> to:
|
||||
- <practical action 1>
|
||||
- <practical action 2>
|
||||
- <practical action 3>
|
||||
|
||||
<Optional availability sentence>
|
||||
```
|
||||
|
||||
### Notion-Style Readability Moves
|
||||
|
||||
Apply these moves when appropriate:
|
||||
|
||||
- Use one clear "scene" sentence to ground context (for example, what a team is doing when the feature helps).
|
||||
- Alternate paragraph lengths: one compact paragraph followed by a denser explanatory one.
|
||||
- Prefer specific nouns (`triage inbox`, `topic switch`, `mobile session`) over broad terms like "experience" or "workflow improvements".
|
||||
- Keep transitions natural (`Previously`, `Now`, `In practice`, `This means`) and avoid ornate writing.
|
||||
- End key sections with a practical takeaway sentence, not a slogan.
|
||||
|
||||
### Anti-Pattern Red Flags (Rewrite Required)
|
||||
|
||||
- "Key Updates" followed by only bullets and no narrative context
|
||||
- One bullet per feature with no prior context or user impact
|
||||
- Repeated template like "Feature X: did Y"
|
||||
- Heading-per-feature with no explanatory paragraph
|
||||
- Mechanical transitions with no causal flow
|
||||
|
||||
### EN/ZH Synchronization Rules
|
||||
|
||||
- Keep section order aligned.
|
||||
- Keep facts and scope aligned.
|
||||
- Localize naturally; avoid literal sentence mirroring.
|
||||
- If one language uses bullets for a section, the other should match style intent.
|
||||
|
||||
### Writing Tips
|
||||
|
||||
- **User-facing**: Describe changes that users can perceive, not internal implementation details
|
||||
- **Clear categories**: Group by features, models/providers, desktop, stability/fixes, etc.
|
||||
- **Highlight key items**: Use `**bold**` for important feature names
|
||||
- **Credit contributors**: Collect all committers via `git log` and list alphabetically
|
||||
- **Flexible categories**: Choose categories based on actual changes — no need to force-fit all categories
|
||||
- **Terminology enforcement**: Ensure wording follows `microcopy` skill terminology and tone constraints
|
||||
- **Linear narrative enforcement**: Follow capability -> explanation -> optional "Use X to" list
|
||||
- **Storytelling enforcement**: For major updates, write in "before -> now -> impact" order
|
||||
- **Depth enforcement**: If the diff is non-trivial, prefer complete paragraphs over compressed bullet-only summaries
|
||||
- **Pleasure-to-read enforcement**: Include concrete examples and practical scenarios so readers can imagine using the capability
|
||||
|
||||
### Quick Checklist
|
||||
|
||||
- [ ] First paragraph explains user-visible release outcome
|
||||
- [ ] Heading count is minimal and meaningful
|
||||
- [ ] Major capabilities are short narrative paragraphs, not only bullets
|
||||
- [ ] Includes "before -> now -> impact" for major sections
|
||||
- [ ] No obvious AI patterns (parallel negation, rhetorical Q/A, dramatic reveal)
|
||||
- [ ] Vocabulary is plain, direct, and product-credible
|
||||
- [ ] Improvements/fixes remain concise and scannable
|
||||
- [ ] Credits format is preserved exactly
|
||||
- [ ] EN/ZH versions align in facts and order
|
||||
>>>>>>> origin/main
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@
|
|||
|
||||
---
|
||||
|
||||
<<<<<<< HEAD
|
||||
## ✨ Highlights
|
||||
|
||||
- **Benchmark Lifecycle Schema** — Added a relational model that tracks benchmark setup, runs, per-topic execution, and record outputs end-to-end.
|
||||
|
|
@ -19,29 +18,6 @@
|
|||
## 🗄️ Migration Overview
|
||||
|
||||
Added tables:
|
||||
=======
|
||||
This release includes a **database schema migration** for Agent Evaluation Benchmark. We are adding **5 new tables** so benchmark setup, runs, and run-topic records can be stored in a complete and queryable structure.
|
||||
|
||||
## Migration overview
|
||||
|
||||
Previously, benchmark-related data lacked a full lifecycle model, which made it harder to track evaluation flow from dataset to run results. This migration introduces the missing relational layer so benchmark configuration, execution, and analysis records stay connected.
|
||||
|
||||
In practical terms, this reduces ambiguity for downstream features and gives operators a cleaner foundation for troubleshooting and reporting.
|
||||
|
||||
Added tables:
|
||||
|
||||
- `agent_eval_benchmarks`
|
||||
- `agent_eval_datasets`
|
||||
- `agent_eval_records`
|
||||
- `agent_eval_runs`
|
||||
- `agent_eval_run_topics`
|
||||
|
||||
## Notes for self-hosted users
|
||||
|
||||
- Migration runs automatically during app startup.
|
||||
- No manual SQL action is required in standard deployments.
|
||||
- As with any schema release, we still recommend database backup and rollout during a low-traffic window.
|
||||
>>>>>>> origin/main
|
||||
|
||||
- `agent_eval_benchmarks`
|
||||
- `agent_eval_datasets`
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@
|
|||
|
||||
---
|
||||
|
||||
<<<<<<< HEAD
|
||||
## ✨ Highlights
|
||||
|
||||
- **Gateway Session Recovery** — Agent sessions now recover more reliably after short network interruptions, so long-running tasks continue with less manual retry. (#10121, #10133)
|
||||
|
|
@ -35,49 +34,6 @@
|
|||
---
|
||||
|
||||
## 📱 Gateway & Platform Integrations
|
||||
=======
|
||||
This weekly release includes **82 commits**. The throughline is simple: less friction when moving from idea to execution. Across agent workflows, model coverage, and desktop polish, this release removes several small blockers that used to interrupt momentum.
|
||||
|
||||
The result is not one headline feature, but a noticeably smoother week-to-week experience. Teams can evaluate agents with clearer structure, ship richer media flows, and spend less time debugging provider and platform edge cases.
|
||||
|
||||
## Agent workflows and media generation
|
||||
|
||||
Previously, some agent evaluation and media generation flows still felt fragmented: setup was manual, discoverability was uneven, and switching between topics could interrupt context. This release adds **Agent Benchmark** support and lands the **video generation** path end-to-end, from entry point to generation feedback.
|
||||
|
||||
In practice, this means users can discover and run these workflows with fewer detours. Sidebar "new" indicators improve visibility, skeleton loading makes topic switches feel less abrupt, and memory-related controls now behave more predictably under real workload pressure.
|
||||
|
||||
We also expanded memory controls with effort and tool-permission configuration, and improved timeout calculation for memory analysis tasks so longer runs fail less often in production-like usage.
|
||||
|
||||
## Models and provider coverage
|
||||
|
||||
Provider diversity matters most when teams can adopt new models without rewriting glue code every sprint. This release adds **Straico** and updates support for Claude Sonnet 4.6, Gemini 3.1 Pro Preview, Qwen3.5, Grok Imagine (`grok-imagine-image`), and MiniMax 2.5.
|
||||
|
||||
Use these updates to:
|
||||
|
||||
- route requests to newly available providers
|
||||
- test newer model families without custom patching
|
||||
- keep model parameters and related i18n copy aligned across providers
|
||||
|
||||
This keeps model exploration practical: faster evaluation loops, fewer adaptation surprises, and cleaner cross-provider behavior.
|
||||
|
||||
## Desktop and platform polish
|
||||
|
||||
Desktop receives a set of quality-of-life upgrades that reduce "death by a thousand cuts" moments. We integrated `electron-liquid-glass` for macOS Tahoe and improved DMG background assets and packaging flow for more consistent release output.
|
||||
|
||||
The desktop editor now supports image upload from the file picker, which shortens everyday authoring steps and removes one more reason to switch tools mid-task.
|
||||
|
||||
## Improvements and fixes
|
||||
|
||||
- Fixed multiple video pipeline issues across precharge refund handling, webhook token verification, pricing parameter usage, asset cleanup, and type safety.
|
||||
- Fixed path traversal risk in `sanitizeFileName` and added corresponding unit tests.
|
||||
- Fixed MCP media URL generation when `APP_URL` was duplicated in output paths.
|
||||
- Fixed Qwen3 embedding failures caused by batch-size limits.
|
||||
- Fixed several UI interaction issues, including mobile header agent selector/topic count, ChatInput scrolling behavior, and tooltip stacking context.
|
||||
- Fixed missing `@napi-rs/canvas` native bindings in Docker standalone builds.
|
||||
- Improved GitHub Copilot authentication retry behavior and response error handling in edge cases.
|
||||
|
||||
## Credits
|
||||
>>>>>>> origin/main
|
||||
|
||||
- Gateway now drains in-flight events more safely before restart, reducing duplicate notification bursts. (#10125)
|
||||
- Discord and Slack adapters received retry/backoff tuning for unstable webhook windows. (#10091, #10119)
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
|
||||
# Changelog
|
||||
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
## [Version 2.1.51](https://github.com/lobehub/lobe-chat/compare/v0.0.0-nightly.pr13850.8503...v2.1.51)
|
||||
|
||||
<sup>Released on **2026-04-16**</sup>
|
||||
|
|
@ -53,7 +51,6 @@
|
|||
|
||||
</div>
|
||||
|
||||
>>>>>>> origin/main
|
||||
## [Version 2.1.50](https://github.com/lobehub/lobe-chat/compare/v2.1.49...v2.1.50)
|
||||
|
||||
<sup>Released on **2026-04-16**</sup>
|
||||
|
|
|
|||
|
|
@ -1,13 +1,6 @@
|
|||
[
|
||||
{
|
||||
"children": {},
|
||||
"date": "2026-04-16",
|
||||
"version": "2.1.50"
|
||||
},
|
||||
{
|
||||
"children": {
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
"fixes": ["fix minify cli.", "recent delete."]
|
||||
},
|
||||
"date": "2026-04-16",
|
||||
|
|
@ -20,7 +13,6 @@
|
|||
},
|
||||
{
|
||||
"children": {
|
||||
>>>>>>> origin/main
|
||||
"improvements": ["add agent task system database schema."]
|
||||
},
|
||||
"date": "2026-03-26",
|
||||
|
|
|
|||
|
|
@ -1,10 +1,6 @@
|
|||
{
|
||||
"name": "@lobehub/lobehub",
|
||||
<<<<<<< HEAD
|
||||
"version": "2.1.50",
|
||||
=======
|
||||
"version": "2.1.51",
|
||||
>>>>>>> origin/main
|
||||
"description": "LobeHub - an open-source,comprehensive AI Agent framework that supports speech synthesis, multimodal, and extensible Function Call plugin system. Supports one-click free deployment of your private ChatGPT/LLM web application.",
|
||||
"keywords": [
|
||||
"framework",
|
||||
|
|
|
|||
|
|
@ -87,15 +87,10 @@ afterEach(() => {
|
|||
const TEST_TIMEOUT_MS = 15_000;
|
||||
|
||||
describe('ModeSwitch', () => {
|
||||
<<<<<<< HEAD
|
||||
it('renders both onboarding variants when agent onboarding is enabled', () => {
|
||||
renderModeSwitch({ enabled: true, showLabel: true });
|
||||
=======
|
||||
it(
|
||||
'renders both onboarding variants when agent onboarding is enabled',
|
||||
async () => {
|
||||
await renderModeSwitch({ enabled: true, showLabel: true });
|
||||
>>>>>>> origin/main
|
||||
() => {
|
||||
renderModeSwitch({ enabled: true, showLabel: true });
|
||||
|
||||
expect(screen.getByText('Choose your onboarding mode')).toBeInTheDocument();
|
||||
expect(screen.getByRole('radio', { name: 'Conversational' })).toBeChecked();
|
||||
|
|
@ -104,9 +99,10 @@ describe('ModeSwitch', () => {
|
|||
TEST_TIMEOUT_MS,
|
||||
);
|
||||
|
||||
<<<<<<< HEAD
|
||||
it('hides the onboarding switch entirely when agent onboarding is disabled', () => {
|
||||
renderModeSwitch({ enabled: false });
|
||||
it(
|
||||
'hides the onboarding switch entirely when agent onboarding is disabled',
|
||||
() => {
|
||||
renderModeSwitch({ enabled: false });
|
||||
|
||||
expect(screen.queryByRole('radio', { name: 'Conversational' })).not.toBeInTheDocument();
|
||||
expect(screen.queryByRole('radio', { name: 'Classic' })).not.toBeInTheDocument();
|
||||
|
|
@ -121,19 +117,6 @@ describe('ModeSwitch', () => {
|
|||
expect(screen.queryByRole('radio', { name: 'Conversational' })).not.toBeInTheDocument();
|
||||
expect(screen.queryByRole('radio', { name: 'Classic' })).not.toBeInTheDocument();
|
||||
});
|
||||
=======
|
||||
it(
|
||||
'hides the onboarding switch entirely when agent onboarding is disabled',
|
||||
async () => {
|
||||
await renderModeSwitch({ enabled: false });
|
||||
|
||||
expect(screen.queryByRole('radio', { name: 'Conversational' })).not.toBeInTheDocument();
|
||||
expect(screen.queryByRole('radio', { name: 'Classic' })).not.toBeInTheDocument();
|
||||
expect(screen.queryByText('Choose your onboarding mode')).not.toBeInTheDocument();
|
||||
},
|
||||
TEST_TIMEOUT_MS,
|
||||
);
|
||||
>>>>>>> origin/main
|
||||
|
||||
it('keeps action buttons visible when agent onboarding is disabled', () => {
|
||||
renderModeSwitch({
|
||||
|
|
|
|||
Loading…
Reference in a new issue