refactor(content): the three values are machine modes, not content types (split Step 3) - #129
Merged
Merged
Conversation
…pes (split Step 3) Steps 1 and 2 gave every piece an AI-written name and put it in front of the three-value key. This step renames the key itself. Its words were 解决 / 分享 / 记录 — content classification words — everywhere the creator reads them, including the question the urgent flow asked: 「这条内容属于哪一类？」. That question is the exact complaint this whole split started from, and it was still being asked, just in fewer places. Now: | where | was | is | |---|---|---| | rubric labels (they drive prompts and copy) | 解决 / 分享 / 记录 | 教方法 / 讲经历 / 记过程 | | confirm panel field | 内容意图 | 处理方式 | | that field's options | 解决：教会一个方法 | 教方法：要问题、你的做法和结果 | | workspace outline item | 内容意图 | 处理方式 | | workspace header (no name yet) | 这是一条分享内容。 | 这条按「讲经历」处理。 | | inference banner | 我理解这是「分享」内容 | 我按「讲经历」来准备这条 | | urgent step 3 | 这条内容属于哪一类？ | AI 按哪种方式帮你？ | | shelf chips / list badge / series / opportunities / starter | 分享意图 … | 讲经历 … | The option tails now say what that mode needs from the creator (「要问题、你的做法和结果」), which is what the rubric's materials list actually is — the same three values still route the state machine, the required publish-judgement fields, the signal vocabulary and the learned-rule applicability match (`content_genome`). No database change: no enum value, no CHECK, no column. The retrospective classification select keeps past-tense tails (「当时在教一个方法」) because there the creator is describing a published piece, not choosing a mode. One copy fix along the way: a series limitation string told the creator to check "content_intent 和 content_format" — it leaked two column names into a user-facing message. It now says the pieces differ in 处理方式 or 格式. Verification: backend 508 passed (ruff clean), frontend 279 passed in 43 files (coverage gate run), tsc and eslint clean, six E2E suites pass locally. Real-stack pass at 1280 and 390 with no overflow (frontend/scripts/taxonomy-step3-shots.mjs; screenshots in browser-screenshots/taxonomy-step3). Step 4 stays untouched and conditional: widening the six CHECK constraints is only needed if a fourth *behaviour* ever appears. Nothing here required it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 3 of the split (#126). Steps 1–2 (#127/#128) gave each piece an AI-written name and put it ahead of the three-value key; this step renames the key itself.
为什么：那三个值的词是内容分类词——解决 / 分享 / 记录。它们出现在用户能读到的每一处，包括急稿第 3 步的问题仍是「这条内容属于哪一类？」。这正是整件事的起点（「内容意图为什么是三个枚举」），只是出现得少了。
改了什么
选项尾巴改成说清这种模式要什么材料（「要问题、你的做法和结果」）——那正是 rubric 里 materials 的真实内容。三个值照旧驱动状态机、发布判断必填字段、信号词表与规则适用性匹配（
content_genome）。数据库零改动：没有改枚举值、没有动 CHECK、没有加列。回溯分类那个下拉保留过去式（「当时在教一个方法」），那里用户在描述一条已发布的内容，不是在选模式。顺带修的一处文案：系列的一条限制说明让用户去检查「content_intent 和 content_format」——两个列名漏进了用户可见文案，现在写成「处理方式或格式不一致」。
验证：后端 508 passed / ruff 干净；前端 43 文件 279 passed（含覆盖率门禁）；tsc、eslint 干净；六条 E2E 本地全过；真实栈 1280 与 390 无溢出越界（
frontend/scripts/taxonomy-step3-shots.mjs，截图在browser-screenshots/taxonomy-step3/）。Step 4 未动且仍是条件性的：只有真的出现第四种行为才需要放宽那六张表的 CHECK，本步不需要。