6aspec 2.0.0-dev.9 → 3.0.0-dev.2

package/.6aspec/rules/brown/brown_archive_sop.md

@@ -4,129 +4,94 @@
 
 **输入**：`/6aspec:brown:archive` 后可选需求名称。
 
-**步骤**
+---
+
+## 步骤
 
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.review` 为 "done"
-   - 如果未完成 Phase 7，询问是否强制归档
+   - 根据流程深度检查前置条件：
+     - **轻量级流程**：确认 `phases.implement` 为 "done"
+     - **标准级流程**：确认 `phases.implement` 为 "done"
+   - 如果未满足前置条件，警告用户并询问是否强制归档
 
 2. **确认归档**
 
    询问用户确认：
    ```
-   问题："确认归档需求 <name>？归档后需求将移至归档目录。"
-   选项：
+   确认归档需求 <name>？归档后需求将移至归档目录，操作不可逆。
    - 是，归档此需求
    - 否，取消归档
    ```
 
 3. **执行归档操作**
 
-   a. **创建归档目录**
-   ```bash
-   mkdir -p 6aspecdoc/brown/.archived/<timestamp>-<name>
-   ```
+   a. 创建归档目录：`6aspecdoc/brown/.archived/<timestamp>-<name>/`
 
-   b. **移动需求目录**
-   ```bash
-   mv 6aspecdoc/brown/<name> 6aspecdoc/brown/.archived/<timestamp>-<name>/
-   ```
+   b. 将 `6aspecdoc/brown/<name>/` 整体移入归档目录
 
-   c. **更新归档状态**
-   在归档目录中创建 `archive-info.json`：
+   c. 在归档目录中创建 `archive-info.json`：
    ```json
    {
      "name": "<name>",
+     "flowDepth": "<flowDepth>",
      "archivedAt": "<timestamp>",
-     "archivedBy": "6aspec:brown",
-     "originalPath": "6aspecdoc/brown/<name>",
-     "archivePath": "6aspecdoc/brown/.archived/<timestamp>-<name>",
-     "completedPhases": 7,
-     "totalTasks": 8,
-     "priority": "P0/P1/P2"
+     "completedPhases": ["analyze", "specs", "design", "tasks", "implement"],
+     "tasks": {
+       "total": <N>,
+       "completed": <N>
+     }
    }
    ```
 
 4. **生成归档摘要**
 
    创建 `6aspecdoc/brown/.archived/<timestamp>-<name>/ARCHIVE-SUMMARY.md`：
+
    ```markdown
    # 归档摘要：<name>
 
-   > **归档时间**: <timestamp>
-   > **优先级**: P0/P1/P2
-   > **完成阶段**: 7/7
-   > **总任务数**: 8
-   > **总工时**: <工时>
+   **归档时间**：<timestamp>
+   **流程深度**：轻量级 / 标准级 / 完整级
+   **任务完成**：<N>/<N>
 
    ## 需求概述
 
-   <从 requirement.md 提取>
-
-   ## 关键成果
-
-   - 数据库变更：<数量> 个表
-   - 代码变更：<数量> 个类
-   - 前端变更：<数量> 个页面
-   - 测试用例：<数量> 个
+   <从 proposal.md 或 analysis.md 提取需求描述>
 
    ## 关键文档
 
-   - 01-understanding.md - 需求理解与现状分析
-   - 02-impact-analysis.md - 影响面分析
-   - 03-technical-design.md - 技术方案设计
-   - 04-tasks-overview.md - 任务拆解
-   - 05-verification-report.md - 验证报告
-   - 06-post-implementation-review.md - 实施后评估
-   - ADR-<name>.md - 架构决策记录（P0）
+   - proposal.md — 需求提案
+   - analysis.md — 需求分析（如果存在）
+   - specs.md — 需求规格
+   - design.md — 技术方案
+   - tasks-overview.md — 任务拆解
+   - verification-report.md — 验证报告（如果存在）
+   - review.md — 实施后评估（如果存在）
 
    ## 经验教训
 
-   <从 06-post-implementation-review.md 提取>
-
-   ## 可复用方案
-
-   <从 06-post-implementation-review.md 提取>
-
-   ## 归档位置
-
-   6aspecdoc/brown/.archived/<timestamp>-<name>/
+   <从 review.md 提取（如果存在），否则省略此节>
    ```
 
-**输出**
+---
+
+## 输出
 
 ```
 ## 需求已归档：<name>
 
-**归档时间**: <timestamp>
-**归档位置**: 6aspecdoc/brown/.archived/<timestamp>-<name>/
-
-### 需求统计
-- 优先级：P0/P1/P2
-- 完成阶段：7/7
-- 总任务数：8
-- 总工时：<工时>
-
-### 关键成果
-<列出关键成果>
-
-### 归档文件
-所有需求文档已移至归档目录，包括：
-- 分析文档（Phase 1-4）
-- 验证报告（Phase 6）
-- 实施后评估（Phase 7）
-- 任务详情
-- 归档摘要
-
-### 查看归档
-可以随时查看归档的需求文档：
-6aspecdoc/brown/.archived/<timestamp>-<name>/
+**归档时间**：<timestamp>
+**归档位置**：6aspecdoc/brown/.archived/<timestamp>-<name>/
+**任务完成**：<N>/<N>
 ```
 
-**防护措施**
-- 如果未完成所有阶段，警告用户并询问是否强制归档
-- 归档前必须确认
+---
+
+## 防护措施
+
+- 根据流程深度检查不同的前置条件
+- 未满足前置条件时警告用户，询问是否强制归档
+- 归档前必须用户确认
 - 归档操作不可逆（除非手动恢复）
-- 保留完整的归档信息和摘要

package/.6aspec/rules/brown/brown_constitution.md

@@ -6,6 +6,17 @@
 
 **所有生成的文档内容必须使用中文**，包括标题、字段名、描述等所有文本内容。
 
+## 时间格式规范
+
+**所有时间戳必须使用东八区（北京时间）格式**：`yyyy-MM-dd HH:mm:ss`
+
+示例：`2026-02-20 12:36:23`
+
+适用范围：
+- status.json 中的 `createdAt`、`lastModified`、`completedAt` 等字段
+- 所有 artifacts 文档中的时间戳（创建时间、完成时间、评估时间等）
+- 归档时使用的时间戳
+
 ## 核心行为规则
 
 1. **阶段化推进**：每个阶段完成后必须停止，等待用户通过显式命令推进

package/.6aspec/rules/brown/brown_continue_sop.md

@@ -30,7 +30,7 @@
    **如果所有阶段都完成 (`phases` 全部为 "done")**：
    - 祝贺用户
    - 显示最终状态
-   - 建议："所有阶段已完成！可以运行 `/6aspec:brown:implement` 开始实施，或运行 `/6aspec:brown:archive` 归档。"
+   - 提示："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
    - 停止
 
    **如果有待执行的阶段**：
@@ -39,27 +39,20 @@
 
    **轻量级流程（lightweight）**：
    - `proposal` → 调用 `/6aspec:brown:proposal`
-   - `design` → 调用 `/6aspec:brown:design`
-   - `tasks` → 调用 `/6aspec:brown:tasks`
-   - `implement` → 调用 `/6aspec:brown:implement`
-
-   **标准级流程（standard）**：
-   - `understand` → 调用 `/6aspec:brown:understand`
    - `specs` → 调用 `/6aspec:brown:specs`
-   - `impact` → 调用 `/6aspec:brown:impact`
    - `design` → 调用 `/6aspec:brown:design`
    - `tasks` → 调用 `/6aspec:brown:tasks`
    - `implement` → 调用 `/6aspec:brown:implement`
+   - 如果 implement 已完成且无待执行阶段 → 提示："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
 
-   **完整级流程（complete）**：
-   - `understand` → 调用 `/6aspec:brown:understand`
+   **标准级流程（standard）**：
+   - `analyze` → 调用 `/6aspec:brown:analyze`
+   - `proposal` → 调用 `/6aspec:brown:proposal`
    - `specs` → 调用 `/6aspec:brown:specs`
-   - `impact` → 调用 `/6aspec:brown:impact`
    - `design` → 调用 `/6aspec:brown:design`
    - `tasks` → 调用 `/6aspec:brown:tasks`
    - `implement` → 调用 `/6aspec:brown:implement`
-   - `verify` → 调用 `/6aspec:brown:verify`
-   - `review` → 调用 `/6aspec:brown:review`
+   - 如果 implement 已完成且无待执行阶段 → 提示："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
 
    **如果所有阶段都被阻塞**：
    - 这不应该发生

package/.6aspec/rules/brown/brown_design_sop.md

@@ -1,155 +1,270 @@
 # 棕地需求 - Design SOP
 
-Phase 3: 技术方案设计
+技术方案设计（Design）- 适用于所有流程级别
+
+> **阶段定位**：Design 的目标是输出"可评审的技术蓝图"，聚焦模块划分、服务边界、数据模型、接口/入口规范、集成方案与迁移/兼容策略。
+> - ✅ 写：架构与模块边界、关键决策（可含 ADR）、数据语义与演进策略、接口/入口规范（含幂等/并发/异常语义）、集成点与失败边界、迁移/兼容/灰度/回滚策略、风险清单（含缓解措施）、验证矩阵（测试分类与测试方式，断言值见 Specs）。
+> - ❌ 不写：代码片段/伪代码/注解、前端逐字段交互表、API 具体出入参字段清单（放 Tasks）、存量表改动的全量 DDL（放 Tasks）。类名/方法名可以出现（用于定位），但不写其实现逻辑。
+> - ✅ 例外：**若新增数据库表**，Design 必须给出 DDL（用于评审关键约束与整体形态）。
+> - **影响粒度**：Design 描述到**类/方法级**（哪个 Service、哪个 Job、哪个 Factory 受影响）；行级精确定位留给 Tasks 阶段。
+> - **格式自由**：各章节用表格还是分节散文，由内容复杂度决定，不强制统一格式。
 
 **输入**：`/6aspec:brown:design` 后可选需求名称。
 
-**步骤**
+---
+
+## 步骤
 
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.impact` 为 "done"
-   - 如果未完成 Phase 2，提示先运行 `/6aspec:brown:impact`
+   - 检查前置阶段：确认 `phases.specs` 为 "done"；如未完成，提示先运行 `/6aspec:brown:specs`
 
 2. **读取前置文档**
 
-   - `6aspecdoc/brown/<name>/requirement.md`
-   - `6aspecdoc/brown/<name>/artifacts/01-understanding.md`
-   - `6aspecdoc/brown/<name>/artifacts/01.5-specs.md`（标准级/完整级）
-   - `6aspecdoc/brown/<name>/artifacts/02-impact-analysis.md`
+   根据 `flowDepth` 读取不同的前置文档：
 
-3. **设计数据库变更方案**
+   **轻量级流程**：
+   - `6aspecdoc/brown/<name>/artifacts/proposal.md`
+   - `6aspecdoc/brown/<name>/artifacts/specs.md`
+   - `6aspecdoc/brown/<name>/explore-summary.md`（如果存在）
 
-   - 字段名、类型、约束
-   - 默认值和历史数据处理
-   - 索引建议
-   - 数据迁移脚本（如需要）
+   **标准级/完整级流程**：
+   - `6aspecdoc/brown/<name>/artifacts/proposal.md`
+   - `6aspecdoc/brown/<name>/artifacts/specs.md`
+   - `6aspecdoc/brown/<name>/artifacts/analysis.md`
 
-4. **设计代码实现方案**
+3. **补充探索代码库（按需，轻量）**
 
-   - 实体类字段添加（含注解）
-   - 业务逻辑实现（含关键代码示例）
-   - 校验逻辑（必填、值域、约束）
-   - 错误提示（使用多语言资源）
+   analyze 阶段已完成主要的代码探索，analysis.md 中已有现有系统结构分析。Design 阶段只在以下情况补充查阅：
+   - 需要了解 analysis.md 未覆盖的**具体实现细节**（如某个 Job 的分页策略、事务边界）
+   - 需要参考**现有类似实现**来决定技术方案（如其他定时任务的幂等方案）
+   - 用户明确要求补充探索
 
-5. **设计前端 UI 方案**
+   探索结果直接用于方案设计，不生成独立文档。轻量级流程无 analysis.md，按需探索现有架构模式与集成点。
 
-   - 各页面字段状态（可编辑/只读/隐藏）
-   - 交互逻辑（下拉选择、提示信息）
-   - 错误提示
-   - 多语言支持
+4. **设计技术方案**
 
-6. **设计测试方案**
+   基于前置文档和补充探索，先判断本次需求的核心复杂度在哪里（数据模型？入口逻辑？集成方案？），从最关键的维度开始设计，其他维度跟随。按需取舍（无关的维度直接省略）：
 
-   - 单元测试（函数级别）
-   - 集成测试（流程级别）
-   - 数据一致性验证（SQL 验证）
+   > **多路径决策**：当某个维度存在多种可行的实现路径时（如同步 vs 异步、加字段 vs 加表、事务边界选择等），先列出选项并说明选择理由，再展开该维度的详细设计。
 
-7. **架构决策记录（P0 需求必须）**
+   **模块划分**：列出本次变更涉及的模块/子系统，明确每个模块的职责边界（1-3 条）和模块间依赖关系。
 
-   如果是 P0 级需求，创建 ADR：
+   **服务边界**：明确数据所有权（source of truth）、状态流转责任、事件发布/消费关系、失败边界与业务表现。
 
-   创建 `6aspecdoc/brown/<name>/artifacts/ADR-<name>.md`：
-   ```markdown
-   # ADR: <决策标题>
+   **接口/入口规范**：将 Specs 的触发类型映射为技术入口，只设计本需求实际存在的入口类型。
 
-   **状态**: 提议中 / 已接受
-   **日期**: <timestamp>
-   **需求**: <name>
+   Specs 触发类型 → 技术入口映射：
 
-   ## 背景
-   <为什么需要做这个决策>
+   | Specs 触发类型 | Design 技术入口 |
+   |---|---|
+   | 用户操作 | REST API（Command API） |
+   | 外部系统触发 | REST API（Command API，对外暴露） |
+   | 事件订阅 | Event Subscribers |
+   | 定时任务 | Scheduled Tasks |
 
-   ## 决策
-   <我们决定采用什么方案>
+   > 后台任务（@Async）不是独立触发类型，在对应入口的执行逻辑中说明即可。
 
-   ## 备选方案
+   每个入口必须覆盖以下维度（格式自由）：
+   - **执行逻辑**：步骤级，到类/方法级，不写代码
+   - **幂等设计**：如何防止重复执行
+   - **并发控制**：是否需要加锁，锁的粒度
+   - **边界与异常**：失败如何处理，是否影响其他数据
+   - **性能考虑**：批量大小、超时、瓶颈
+   - **补偿/重试**：失败后是否重试（REST API 无此项）
 
-   | 方案 | 优点 | 缺点 | 为何不选 |
-   |------|------|------|----------|
-   | 方案A | ... | ... | ... |
-   | 方案B | ... | ... | ... |
+   明确各入口的一致性要求（强一致/最终一致）。REST API 的入参/出参字段结构放 Tasks 阶段落地。
 
-   ## 后果
+   **集成方案**：列出所有集成点，明确集成方式（同步/异步/回调）、责任边界、失败语义、可观测性要求。
 
-   - 正面影响：...
-   - 负面影响：...
-   - 技术债务：...
-   - 风险：...
+   **数据模型与数据库方案**：对齐 Specs 的 Key Entities，说明关键业务对象如何落库（表级），列出受影响的表与改动原因，明确关键数据约束。新增表必须给出 DDL；修改存量表只写字段语义/约束/迁移策略，具体 ALTER 放 Tasks。
 
-   ## 验证方式
-   <如何验证这个决策是正确的>
-   ```
+   **迁移 / 兼容**：存量数据处理策略、行为兼容、数据兼容、集成兼容、发布策略（是否灰度）、回滚策略。
+
+   **风险与验证矩阵**：
+   - 风险清单：3-7 个关键风险，每条附缓解措施
+   - 验证矩阵：将 Specs 的 AC / Scenarios 映射为测试分类和测试方式
+
+   验证矩阵格式（"测试方式"列只写如何测，不重复 Specs 的断言值）：
+
+   | Specs AC / Scenario | 测试类型 | 测试方式 |
+   |---------------------|----------|----------|
+   | <AC 组或 Scenario 名> | 单元/集成/回归/人工 | <Mock 策略或测试数据构造方式> |
+
+5. **创建技术方案文档**
+
+   创建 `6aspecdoc/brown/<name>/artifacts/design.md`
+
+   **必须覆盖的章节**（格式自由，按内容复杂度选择表格或散文）：
+   - 背景与目标 / 非目标
+   - 模块划分
+   - 服务边界
+   - 接口/入口规范
+   - 集成方案
+   - 数据模型与数据库方案（新增表附 DDL）
+   - 迁移 / 兼容 / 灰度 / 回滚
+   - 风险与验证矩阵
+
+   **可选章节**（按需加入）：
+   - **What Changes**（变更摘要对比表，适合改动范围清晰的需求）：
+
+     ```markdown
+     ## What Changes
+
+     | 变更前 | 变更后 |
+     |--------|--------|
+     | <旧行为/旧结构> | <新行为/新结构> |
+     | <不变的部分> | 不变 |
+     ```
+
+   - **ADR**（涉及关键架构决策时，创建 `artifacts/ADR-<name>.md`）：
+
+     ```markdown
+     # ADR: <决策标题>
+
+     **状态**: 提议中 / 已接受
+     **日期**: <timestamp>
+
+     ## 背景
+     <为什么需要做这个决策>
+
+     ## 决策
+     <我们决定采用什么方案>
+
+     ## 备选方案
+     | 方案 | 优点 | 缺点 | 为何不选 |
+     |------|------|------|----------|
 
-8. **技术债务识别**
+     ## 后果
+     - 正面影响：...
+     - 负面影响：...
+     - 风险：...
+     ```
 
-   识别实现过程中可能引入的技术债务：
+   - **技术债务**（本次变更引入或暴露的债务，说清楚描述、类型、影响、优先级）
 
-   | 债务ID | 描述 | 类型 | 影响 | 偿还成本 | 优先级 |
-   |--------|------|------|------|----------|--------|
-   | DEBT-001 | 临时的硬编码逻辑 | 代码质量 | 中 | 2人日 | P1 |
+6. **更新状态**
 
-9. **创建技术方案文档**
+   更新 `6aspecdoc/brown/<name>/status.json`：
 
-   创建 `6aspecdoc/brown/<name>/artifacts/03-technical-design.md`
+   **轻量级流程**：
+   ```json
+   {
+     "status": "tasks_pending",
+     "flowDepth": "lightweight",
+     "phases": {
+       "proposal": "done",
+       "specs": "done",
+       "design": "done",
+       "tasks": "pending",
+       "implement": "blocked"
+     },
+     "artifacts": ["proposal.md", "specs.md", "design.md"]
+   }
+   ```
+
+   **标准级流程**：
+   ```json
+   {
+     "status": "tasks_pending",
+     "flowDepth": "standard",
+     "phases": {
+       "analyze": "done",
+       "proposal": "done",
+       "specs": "done",
+       "design": "done",
+       "tasks": "pending",
+       "implement": "blocked"
+     },
+     "artifacts": ["analysis.md", "proposal.md", "specs.md", "design.md"]
+   }
+   ```
 
-10. **更新状态**
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Tasks 待开始`
+   - 更新"最后修改"时间戳
+   - 更新"当前阶段"为 `Design - 技术方案设计（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:tasks 继续下一阶段`
+   - 在"进度概览"中标记 Design 阶段为已完成 `[x]`
 
-    更新 `6aspecdoc/brown/<name>/status.json`：
-    ```json
-    {
-      "status": "tasks_pending",
-      "phases": {
-        "understand": "done",
-        "impact": "done",
-        "design": "done",
-        "tasks": "pending",
-        ...
-      }
-    }
-    ```
+---
 
-**输出**
+## 输出
 
+**轻量级流程**：
 ```
-## Phase 3 完成：技术方案设计
+## Design 完成：<name>
 
-**需求**: <name>
-**进度**: 4/5 阶段完成（标准级）或 4/6 阶段完成（完整级）
+**流程**: 轻量级
+**进度**: 3/5 阶段完成
 
 ### 方案概要
-- 数据库变更：<数量> 个表
-- 代码变更：<数量> 个类
-- 前端变更：<数量> 个页面
-- 测试用例：<数量> 个
+- 模块划分：<数量> 个模块（新增/调整：<数量>）
+- 接口/入口：<数量> 个
+- 集成点：<数量> 个
+- 迁移/兼容：<是否需要 + 简述>
 
 ### 关键设计决策
-<列出 2-3 个关键决策>
+<列出 2-3 个关键决策（含是否创建 ADR）>
+
+### 文档位置
+- 6aspecdoc/brown/<name>/artifacts/design.md
+
+### 下一步
+- 直接回复修正设计方案或补充细节 → 我会更新本阶段文档（design.md）
+- 运行 `/6aspec:brown:tasks` → 进入任务拆解阶段
+- 运行 `/6aspec:brown:continue` → 自动进入下一阶段
+```
+
+**标准级/完整级流程**：
+```
+## Design 完成：<name>
 
-### 技术债务
-<列出识别的技术债务>
+**流程**: <标准级/完整级>
+**进度**: <N/M 阶段完成>
+
+### 方案概要
+- 模块划分：<...>
+- 接口/入口：<...>
+- 集成点：<...>
+- 数据模型：<新增表/改表概览>
+- 迁移/兼容：<策略摘要>
+
+### 风险与验证
+- 关键风险：<数量>
+- 验证矩阵：已覆盖 Specs 的 AC / Scenarios
 
 ### 文档位置
-- 6aspecdoc/brown/<name>/artifacts/03-technical-design.md
-- 6aspecdoc/brown/<name>/artifacts/ADR-<name>.md (P0)
+- 6aspecdoc/brown/<name>/artifacts/design.md
+- 6aspecdoc/brown/<name>/artifacts/ADR-<name>.md（如涉及）
 
 ### 下一步
-- 直接回复修正设计方案或补充细节 → 我会更新本阶段文档（03-technical-design.md）
+- 直接回复修正设计方案或补充细节 → 我会更新本阶段文档（design.md）
 - 运行 `/6aspec:brown:tasks` → 进入任务拆解阶段
 - 运行 `/6aspec:brown:continue` → 自动进入下一阶段
 ```
 
-**用户补充信息时的处理**
+---
+
+## 用户补充信息时的处理
 
-当用户修正设计方案、补充技术细节、或对设计决策提出异议时（未使用阶段命令）：
-1. 将用户的修正/补充整合到 `03-technical-design.md` 的对应章节
+当用户修正设计方案、补充决策信息、或对设计决策提出异议时（未使用阶段命令）：
+1. 将用户的修正/补充整合到 `design.md` 的对应章节
 2. 展示变更摘要
 3. 再次提示：可以继续补充，或通过命令进入下一阶段
 4. **禁止**：不得自动进入下一阶段
 
-**防护措施**
-- 必须先完成 Phase 2
-- P0 需求必须创建 ADR
-- 代码示例必须完整可用
-- 技术债务必须明确标注
+---
+
+## 防护措施
+
+- 必须先完成 specs 阶段（`phases.specs == done`）
+- Design 文档必须覆盖：模块划分、服务边界、接口/入口规范、集成方案、数据模型、迁移/兼容、风险与验证
+- 接口/入口规范必须覆盖：执行逻辑、幂等、并发、异常、性能、补偿/重试（REST API 无补偿项）；格式不限
+- 影响粒度到类/方法级，类名/方法名可以出现（用于定位），不写实现逻辑；行级定位留给 Tasks
+- **禁止**：代码片段/伪代码/注解/前端逐字段交互/API 出入参字段清单
+- **新增表**：必须提供 DDL；**改表**：不得在 Design 展开全量 DDL（放 Tasks）
+- 涉及关键架构决策时必须创建 ADR
+- 标准级/完整级：技术债务应明确标注（如有）
+- 验证矩阵的"测试方式"列不得重复 Specs 中已有的断言值