wsb1224
e3479f0546
# 问题 修复 文件 1 前端构建失败（引号错误） size="small type=" → size="small" type=" PosterHistoryPage.vue 2 migrate_014 ORM vs 缺失列 全部改为原始 SQL，不再引用 ORM 模型 migrate_014.py 3 cleanup 字段名错误 output_path → ppt_path cleanup.py 4 文案生成 case 越权 添加 case.user_id != user_id 校验 poster/service.py 5 存储路径未接通持久化卷 全部改用 get_storage_root()（默认 /app/api/storage/insurance） config.py, ppt/routes.py, poster/service.py, poster/tasks.py 高风险问题修复 # 问题 修复 文件 6 migrate_019 rollback 撤销成功字段 每个 ALTER 后立即 commit，失败只回滚当前语句 migrate_019.py 7 迁移锁 Windows 不兼容 + 句柄未持久化 全局变量保存锁句柄，支持 Windows msvcrt api/insurance/db/__init__.py 8 PDF 校验异常时放行 异常返回 False（文件损坏） security.py 9 健康检查始终返回成功 缺少关键资源时返回 503 + missing 列表 poster/routes.py 10 短密钥掩码泄露原值 ≤4 字符返回 **** ppt_admin_service.py 11 设置无键名白名单 添加 _ALLOWED_SETTING_KEYS 白名单 ppt_admin_service.py 12 容器重启任务永久 stuck 添加 recover_stale_tasks() 启动恢复函数 poster/tasks.py, ppt/parse_worker.py
95 lines
4.5 KiB
Markdown
95 lines
4.5 KiB
Markdown
> **Additional context needed**: audience knowledge and emotional state.
|
|
|
|
Rewrite unclear interface text so users understand what happened, what matters, and what to do next. Preserve factual meaning, product terminology, and brand voice.
|
|
|
|
## Audit the language
|
|
|
|
Read the entire interaction path, not isolated strings. Identify:
|
|
|
|
- ambiguous nouns, verbs, and actions;
|
|
- internal jargon or assumed knowledge;
|
|
- vague labels, outcomes, and system states;
|
|
- missing consequences, recovery, or timing;
|
|
- inconsistent terminology and capitalization;
|
|
- redundant headings, intros, helper text, and confirmations;
|
|
- text that breaks at realistic widths or in translation;
|
|
- tone that ignores stress, risk, success, or urgency.
|
|
|
|
Infer audience and task from product context and surrounding UI. Ask before changing factual claims, legal meaning, or a term that may be domain-specific.
|
|
|
|
## Set the message hierarchy
|
|
|
|
For each state, decide:
|
|
|
|
1. the one fact the user needs now;
|
|
2. the action available next;
|
|
3. supporting context that changes the decision;
|
|
4. the appropriate tone for this moment.
|
|
|
|
Say each idea once. If the heading already explains the state, the introduction should add new information or disappear.
|
|
|
|
## Rewrite by function
|
|
|
|
### Actions and navigation
|
|
|
|
Use a specific verb and object when the outcome is not already obvious. Labels should describe what will happen, not the gesture used to trigger it. Keep the same noun and verb for the same concept throughout the product.
|
|
|
|
For destructive actions, name the object and consequence. Prefer undo over confirmation when recovery is safe. When confirmation is necessary, name the action on both the message and button instead of using `Yes`, `No`, `OK`, or `Submit`.
|
|
|
|
### Forms
|
|
|
|
Use persistent labels; placeholders are examples, not labels. Put format and eligibility requirements before submission. Explain why information is requested only when it is not obvious. Required and optional treatment should be consistent.
|
|
|
|
Validation says what needs attention and how to correct it without blaming the user. Keep related instructions near the field and announce errors accessibly.
|
|
|
|
### Errors and permissions
|
|
|
|
An actionable error answers:
|
|
|
|
1. what failed;
|
|
2. why, when known and useful;
|
|
3. how to recover or what alternative remains.
|
|
|
|
Do not expose internal codes as the primary message. Do not promise a cause or resolution the system cannot know. Treat privacy, payment, deletion, access loss, and blocked work seriously; warmth is welcome, jokes are not.
|
|
|
|
### Loading, empty, and success states
|
|
|
|
Loading text names the real operation and sets an honest expectation when the wait is meaningful. Show determinate progress when available; never invent progress.
|
|
|
|
An empty state distinguishes first use, no results, filters, permissions, and failure. Explain the state and provide the next useful action.
|
|
|
|
Success confirms the completed outcome and mentions the next consequence only when it changes what the user should do. Routine success should be brief.
|
|
|
|
### Help and instructional text
|
|
|
|
Helper text answers an implicit question instead of restating the control. Use progressive disclosure for uncommon detail. Link text must make sense out of context; icon-only controls need accessible names.
|
|
|
|
## Voice, accessibility, and localization
|
|
|
|
Voice stays consistent; tone adapts to the moment. Use plain language without flattening terminology the audience genuinely knows.
|
|
|
|
- Write complete translatable messages rather than concatenated fragments.
|
|
- Keep variables and numbers structured so translators can reorder them.
|
|
- Allow expansion instead of abbreviating prematurely.
|
|
- Make alt text convey the image's information; use empty alt for decoration.
|
|
- Keep screen-reader names aligned with visible labels and outcomes.
|
|
- Do not rely on punctuation, color, or iconography to carry the message alone.
|
|
|
|
Maintain a short terminology glossary when inconsistency spans the product. Do not vary words for literary effect in an interface.
|
|
|
|
## Verify
|
|
|
|
Read the flow in context and test:
|
|
|
|
- comprehension without hidden product knowledge;
|
|
- actionability at errors, empty states, and decision points;
|
|
- factual accuracy and consistent terminology;
|
|
- scanability at target widths and 200% zoom;
|
|
- long names, localization expansion, pluralization, and dynamic values;
|
|
- accessible names and announced state changes;
|
|
- tone appropriate to consequence and emotional context.
|
|
|
|
The final copy is as short as it can be without removing meaning or recovery.
|
|
|
|
When the language reads cleanly, hand off to `/impeccable polish` for the final pass.
|