docs(planning): define RESP allocation guardrails

Record the approved parser resource-limit design, TDD execution steps, and the transition from merged PR #388 to the RESP-LIMITS-001 implementation card.

Constraint: This commit changes planning and recovery-facing documentation only; runtime behavior remains unchanged.

Confidence: High; the scope follows exact main source inspection and Redis 8.8.1 parser evidence.

Scope-risk: Low; only task-specific design, plan, STATE, and KANBAN files are included.

Tested: git diff --cached --check; placeholder scan; Requirement and task identifier scan.

Not-tested: Runtime tests are deferred to the implementation commit.

Co-authored-by: OmX <omx@oh-my-codex.dev>

Author: AlexStocks

.planning/KANBAN.md

@@ -1,10 +1,10 @@
 # Kiwi Kanban
 
-> 更新日期：2026-07-30
+> 更新日期：2026-07-31
 >
 > 当前里程碑：M1 Redis 8.8.1 Cache OFF compatibility foundation
 >
-> 当前 task：PR `#388` implementation（`feat/rocksdb-build-accel-and-prd`）；已验证远端 Base `0f8d96238860a5c29a5582e461e4cdeb974431b3`、Head `b47cb1eebe098e2d4d2d784020dc283a8d026d28`
+> 当前 task：`RESP-LIMITS-001` implementation（`codex/fix-resp-parser-limits`）；基线 `main` at `cbc28958f261ae049d67a8b4a9d904d794b37726`
 >
 > 当前运行模式：Cache OFF
 >
@@ -14,7 +14,7 @@
 
 | ID | 工作项 | Requirement / Gate 关系 | 当前状态 |
 |---|---|---|---|
-| `PR388-001` | C/C++ sccache 构建接入、跨平台回归探针、PRD/用户故事及 review 一致性修复 | `REQ-STABILITY-003`、`REQ-WORK-001`、`REQ-WORK-003`、`REQ-WORK-005`；跨平台构建修复只维护 G6 CI 的可执行性与证据条件，不构成 Gate 通过证据 | 本地针对性验证通过并形成提交；远端发布状态和新 Head CI 结果以 PR/checks/threads 实时查询为准 |
+| `RESP-LIMITS-001` | 限制未认证 RESP Array/Map/Set/Push 声明长度和初始预分配 | `REQ-COMPAT-002`、`REQ-COMPAT-006`、`REQ-WORK-003` | 设计已批准；独立 worktree 与 recovery checkpoint 已建立；正在执行 parser TDD |
 
 ## Ready for a separate implementation task
 
@@ -37,6 +37,7 @@
 | ID | 工作项 | Evidence | 状态 |
 |---|---|---|---|
 | `M1-001-T1` | Redis 8.8.1 exact compatibility manifest | PR `#372`；final Head `6a692bc195f96327296296977a100af301deaf01`；merge commit `9e91707d774ad367d682e23677dcef79ecb14338` | 已合并到 `main` |
+| `PR388-001` | C/C++ sccache 构建接入、跨平台回归探针、PRD/用户故事及 review 一致性修复 | PR `#388`；final Head `1ee8c916a55d03d02a250ed95af83712fa14a742`；2026-07-30 merged | 已合并到 `main` |
 
 ## Frozen unaccepted drafts
 
@@ -89,7 +90,7 @@
 
 ## WIP 与授权规则
 
-- 同一时间只允许一个 implementation card 处于 In Progress；当前为 `PR388-001`，planning/docs task 不得隐式持有 implementation card。
+- 同一时间只允许一个 implementation card 处于 In Progress；当前为 `RESP-LIMITS-001`，planning/docs task 不得隐式持有 implementation card。
 - 规划批准不授权修改 source、tests、build scripts 或 CI，也不授权 stage/commit/push 实现文件。
 - 从 planning 转 implementation 必须创建新 Codex task、TaskId、worktree、dirty allowlist 和 recovery checkpoint；不能只把 recovery mode 从 `planning` 改成 `implementation`。
 - 冻结草稿不得覆盖、续写、清理或回退；后续实施只读参考并重新审计。

.planning/STATE.md

@@ -1,45 +1,46 @@
 # Kiwi 当前状态
 
-> 更新时间：2026-07-30
+> 更新时间：2026-07-31
 >
 > 当前 task 类型：implementation
 >
-> 当前 PR：`#388`（`feat/rocksdb-build-accel-and-prd`）
+> 当前 PR：待创建（`codex/fix-resp-parser-limits`）
 >
-> 已验证远端快照：Base `main` at `0f8d96238860a5c29a5582e461e4cdeb974431b3`；Head `b47cb1eebe098e2d4d2d784020dc283a8d026d28`
+> 实现基线：`main` at `cbc28958f261ae049d67a8b4a9d904d794b37726`
 >
-> 状态：PR `#388` 在 2026-07-30 复检时为 OPEN；本轮 review fix 已形成提交，发布状态、checks 和 review threads 必须实时查询
+> 状态：设计已批准，独立 worktree 与恢复 checkpoint 已建立；正在执行 parser TDD
 >
-> 当前范围：修复 C/C++ sccache 的 Windows 编译器回归和重复 `target` 缓存，补充自动回归探针，并统一版本化 PRD、用户故事与项目状态
+> 当前范围：拒绝超出 Redis 8.8.1 整数边界的 RESP 聚合长度，并限制 Array/Map/Set/Push 的初始预分配
 >
-> Requirement 边界：`REQ-STABILITY-003`、`REQ-WORK-001`、`REQ-WORK-003`、`REQ-WORK-005`；跨平台构建修复只维护 G6 CI 的可执行性与证据条件，不构成任何稳定性 Gate 已通过的证据
+> Requirement 边界：`REQ-COMPAT-002`、`REQ-COMPAT-006`、`REQ-WORK-003`
 
 ## 当前目标
 
-PR `#388` 是与 PR `#383` 规划任务分离的 implementation task。其既有范围是在 CI 与 `scripts/dev.sh` 中为 RocksDB C/C++ 编译接入 sccache，并新增由权威规划文档综合出的 PRD 与用户故事。本轮 review fix 处理 Windows compiler wrapper 回归、重复缓存、自动回归探针、文档 Requirement 映射、Hot Tier 授权边界和当前项目状态问题。
+本 task 修复 Issue #395 B1 中已经由源码确认的未认证 RESP 聚合类型无界预分配问题。客户端声明长度不得直接控制 `Vec` 的初始容量；超出 Redis 8.8.1 `INT_MAX` 边界的声明返回协议错误，合法声明的初始容量最多为 1024。
 
-本 task 不实现 Redis Oracle provenance，不接受旧六文件 Oracle 草稿，也不启动 Embedded Redis Hot Tier。PR `#388` 的合并、CI 通过或 M7 Ready 均不能替代 Oracle implementation task 或 Hot Tier implementation task 的单独授权。
+本 task 不处理实际流入的超大 bulk 或连接累计 buffer 限额，不修改 PR #402 的文档，不处理 Issue #395 的其他条目，也不实现 Redis Oracle provenance 或 Embedded Redis Hot Tier。
 
 ## 当前授权边界
 
 允许：
 
-- 在本轮 review fix 中修改 `.github/workflows/ci.yml`、`scripts/dev.sh`、`scripts/tests/test-dev-sccache-env.sh`、`docs/prd.md`、`docs/personas-and-user-stories.md`、`.planning/STATE.md` 和 `.planning/KANBAN.md`。
-- 执行 Markdown、链接、Requirement/Decision ID、一致性和 Git diff 等只读检查。
-- 记录已经发生并可验证的 PR/Base/Head 历史；瞬时 checks、threads 和 dirty ownership 继续实时查询。
+- 修改 `src/resp/src/parse.rs`、本 task 的设计/计划、`.planning/STATE.md` 和 `.planning/KANBAN.md`。
+- 运行 resp crate 单测、Clippy、格式检查、Git diff 检查及与 changed surface 对应的验证。
+- commit、push 并创建以 `main` 为 base 的独立 PR；发布后实时查询 checks 和 review threads。
 
 禁止：
 
-- 修改 Cargo、生产源码、Oracle provenance 实现、Hot Tier 实现或其他未授权路径。
+- 修改 Cargo、网络/认证逻辑、其他生产源码、PR #402 文档、Oracle provenance 或 Hot Tier 实现。
 - 在旧 `redis-8.8.1-stability-foundation` worktree 继续、暂存、提交、push、清理或回退六文件实现草稿。
 - 把旧草稿的绿色测试、审查或真实构建准备表述为方案 A 已实现。
 - 扩大到 Embedded Redis Hot Tier、Redis fork、动态库、loader、Cache ON 或组合发行实现。
-- 在未获授权时 commit、push、merge、rebase、Resolve 或回复 GitHub review thread。
+- merge、rebase、Resolve 或回复 GitHub review thread。
 
 ## 已确认决定
 
 - PR `#383` 已于 2026-07-28 合并：final Head `42c16bef899385bd2e1b1e16e2e0202d4a614590`，merge commit `58030e1331655546ea4547a9a94efc493534ef7d`；它只完成 Oracle 方案 A 的规划闭环。
-- PR `#388` 是独立 implementation task，不得继承或隐式扩大 PR `#383` 的 Oracle 实施授权。
+- PR `#388` 已于 2026-07-30 合并；本 task 是从最新 `main` 创建的独立 implementation task。
+- RESP 聚合长度上限采用 Redis 8.8.1 的 `INT_MAX`，初始预分配上限采用 1024。
 - `D011`：Redis Oracle required provenance 采用 verifier fresh-checkout independent rebuild 和 exact binary hash equality。
 - `D012`：规划 task 与实施 task 分离；规划批准不授权源码实现，提前产生的实现草稿冻结。
 - Redis 8.8.1 tag `8.8.1` / commit `77b6c308396c9700672390a210143a8496fb4b10` 是唯一兼容和 Oracle 基线。
@@ -60,11 +61,11 @@ PR `#388` 是与 PR `#383` 规划任务分离的 implementation task。其既有
 - 规划状态：方案 A 的 15 路径 planning-only Diff 已由 PR `#383` 合并；final Head `42c16bef899385bd2e1b1e16e2e0202d4a614590`，merge commit `58030e1331655546ea4547a9a94efc493534ef7d`。
 - 实施状态：未在已接受边界中开始。
 - 实施入口：`docs/superpowers/plans/2026-07-28-redis-8.8.1-trusted-oracle-provenance.md`。
-- 启动条件：另开专用于 Oracle provenance 的 implementation task，从包含本规划的 clean commit 创建新 worktree，保存新 TaskId 和 recovery checkpoint；当前 PR `#388` 不满足或替代该条件。
+- 启动条件：另开专用于 Oracle provenance 的 implementation task，从包含本规划的 clean commit 创建新 worktree，保存新 TaskId 和 recovery checkpoint；当前 RESP parser task 不满足或替代该条件。
 
 ## 冻结实现草稿
 
-相关但不属于当前 PR `#388` dirty ownership：
+相关但不属于当前 RESP parser task dirty ownership：
 
 ```text
 Worktree:
@@ -98,7 +99,9 @@ D:\test\github\kiwi\.worktrees\redis-8.8.1-stability-foundation\.codex\recovery\
 - PR `#372` 的合并状态、final Head 和 `main` merge commit 已实时确认。
 - PR `#383` 已合并；其规划提交只涉及 15 个 planning/docs 路径，并从 Task 1 合并后的 `main` 重放，未带入 Cargo、脚本、CI 或实现路径。
 - 旧六文件草稿 worktree 已只读核对，并继续冻结。
-- PR `#388` 的远端审查快照为 Base `0f8d96238860a5c29a5582e461e4cdeb974431b3`、Head `b47cb1eebe098e2d4d2d784020dc283a8d026d28`；本轮 review fix 已形成提交，当前发布状态须通过 GitHub 实时查询。
+- PR `#388` 已于 2026-07-30 合并，final Head `1ee8c916a55d03d02a250ed95af83712fa14a742`。
+- 本 task 已确认 `RespParse` 在认证前可达；Array/Map/Set/Push 均把未受信任的 `i64` 长度直接传给 `Vec::with_capacity`。
+- Redis 8.8.1 exact tag 的 multibulk parser 拒绝大于 `INT_MAX` 的声明值，并把初始 argv 分配限制为 1024。
 - `wsl.exe --cd /mnt/d/test/github/review/kiwi-pr-388/source -- bash scripts/tests/test-dev-sccache-env.sh`：7 个 Windows/Unix/compiler 场景全部 PASS。
 - WSL Python/PyYAML 解析 `.github/workflows/ci.yml`：8 个 job 可解析，手写 `actions/cache` 的 `target` owner 为 0，compiler regression probe 恰有 1 个 CI step。
 - 文档一致性探针：59 个使用中的 `REQ-*`、4 个 `D*` 均能在权威文件解析，Markdown 表格结构通过。
@@ -109,8 +112,9 @@ PR `#383` 的结果只证明 Oracle 规划闭环，不证明方案 A 已实现
 
 ## 下一条安全动作
 
-1. 对本轮七个 task-owned 路径执行 shell 回归、workflow YAML、Markdown、引用、Requirement/Decision ID、Git diff 和路径边界检查。
-2. 本轮 push 已获得单独授权；发布后重新查询新 Head 的 checks。Resolve 或回复 review thread 仍须对应的单独授权，不得把已发布提交表述为 CI 已验证内容。
+1. 先运行超限 frame 回归并保留预期红灯，再实现统一容量 helper。
+2. 运行 `cargo test -p resp`、目标 Clippy、`cargo fmt --check` 和 `git diff --check`。
+3. 本轮 push 和创建独立 PR 已获得授权；发布后重新查询新 Head 的 checks。不得把未完成的 CI 表述为通过。
 3. PR `#383` 的规划历史保持不变，旧六文件 Oracle 草稿继续冻结。
 4. 只有用户另开 Oracle provenance implementation task 后，才从包含方案 A 的 clean `main` 创建新 worktree、TaskId 和 recovery checkpoint，并先执行真实 Redis 双 checkout reproducibility 门禁。
 5. Hot Tier 继续 Frozen；Gate PASS 后仍须用户明确批准一个单独的 implementation task。
@@ -127,7 +131,7 @@ Get-Content -Raw docs\personas-and-user-stories.md
 if (Test-Path .codex\recovery\ACTIVE.md) { Get-Content -Raw .codex\recovery\ACTIVE.md }
 git status --porcelain=v2 --branch --untracked-files=all
 git diff --cached --name-only
-gh pr view 388 -R arana-db/kiwi --json state,baseRefOid,headRefOid,statusCheckRollup,reviewDecision
+gh pr list --repo arana-db/kiwi --head codex/fix-resp-parser-limits --json number,state,baseRefName,headRefOid,statusCheckRollup,reviewDecision
 ```
 
 如果 branch、HEAD、task type 或 dirty ownership 与 recovery 记录不同，先报告差异，不得自动 checkout、restore、reset、stash、clean 或覆盖文件。

docs/superpowers/plans/2026-07-31-resp-parser-resource-limits.md

@@ -0,0 +1,156 @@
+# RESP 聚合类型资源限额实现计划
+
+> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers:executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。
+
+**目标：** 阻止未认证客户端通过 RESP 聚合类型声明长度触发无界初始分配或 capacity-overflow panic。
+
+**架构：** 在 `resp` crate 内增加一个统一的聚合容量校验 helper，按 Redis 8.8.1 的 `INT_MAX` 边界拒绝超限声明，并把初始容量限制为 1024。四种聚合解析器共享该 helper，网络层继续复用现有协议错误关闭连接路径。
+
+**技术栈：** Rust 2024、`nom` streaming parser、`bytes`、Cargo tests、Clippy
+
+---
+
+## 文件结构
+
+- 修改：`src/resp/src/parse.rs`，包含聚合长度校验、Array/Map/Set/Push 调用点和回归测试。
+- 创建：`docs/superpowers/specs/2026-07-31-resp-parser-resource-limits-design.md`，冻结问题、边界与验收合同。
+- 创建：`docs/superpowers/plans/2026-07-31-resp-parser-resource-limits.md`，记录 TDD 实施步骤。
+- 修改：`.planning/STATE.md`，记录当前实现任务、授权边界和验证结果。
+- 修改：`.planning/KANBAN.md`，把已合并 PR #388 归档并登记唯一进行中的 `RESP-LIMITS-001`。
+
+### 任务 1：建立会安全失败的超限回归测试
+
+**文件：**
+- 修改：`src/resp/src/parse.rs` 的 `tests` 模块
+
+- [ ] **步骤 1：编写失败测试**
+
+```rust
+#[test]
+fn test_reject_oversized_aggregate_lengths_without_panicking() {
+    for frame in [
+        "*9223372036854775807\r\n",
+        "%9223372036854775807\r\n",
+        "~9223372036854775807\r\n",
+        ">9223372036854775807\r\n",
+    ] {
+        let mut parser = RespParse::new(RespVersion::RESP3);
+        let result = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
+            parser.parse(Bytes::copy_from_slice(frame.as_bytes()))
+        }));
+
+        assert!(matches!(result, Ok(RespParseResult::Error(_))), "{frame:?}");
+    }
+}
+```
+
+- [ ] **步骤 2：运行测试验证失败**
+
+运行：`cargo test -p resp test_reject_oversized_aggregate_lengths_without_panicking -- --exact --nocapture`
+
+预期：FAIL；现有实现发生 `capacity overflow`，`catch_unwind` 返回 `Err`，断言失败。
+
+### 任务 2：实现统一的有界初始容量
+
+**文件：**
+- 修改：`src/resp/src/parse.rs` 的常量、helper 和四个聚合解析函数
+
+- [ ] **步骤 1：增加常量和 helper**
+
+```rust
+const MAX_AGGREGATE_LENGTH: i64 = i32::MAX as i64;
+const MAX_PREALLOCATED_AGGREGATE_LENGTH: usize = 1024;
+
+fn aggregate_capacity(
+    input: &[u8],
+    len: i64,
+) -> Result<usize, nom::Err<nom::error::Error<&[u8]>>> {
+    if len > MAX_AGGREGATE_LENGTH {
+        return Err(nom::Err::Failure(nom::error::Error::new(
+            input,
+            nom::error::ErrorKind::Verify,
+        )));
+    }
+
+    usize::try_from(len)
+        .map(|len| len.min(MAX_PREALLOCATED_AGGREGATE_LENGTH))
+        .map_err(|_| {
+            nom::Err::Failure(nom::error::Error::new(
+                input,
+                nom::error::ErrorKind::Verify,
+            ))
+        })
+}
+```
+
+- [ ] **步骤 2：在四个调用点使用 helper**
+
+各解析函数完成负数语义处理后调用 `Self::aggregate_capacity(input, len)?`，并把返回值传给 `Vec::with_capacity`。Map 的声明值表示 pair 数，不做乘二预分配。
+
+- [ ] **步骤 3：运行红灯测试并确认转绿**
+
+运行：`cargo test -p resp test_reject_oversized_aggregate_lengths_without_panicking -- --exact --nocapture`
+
+预期：PASS；四种 frame 均返回 `RespParseResult::Error`，没有 panic。
+
+### 任务 3：覆盖最大合法边界并验证兼容行为
+
+**文件：**
+- 修改：`src/resp/src/parse.rs` 的 `tests` 模块
+
+- [ ] **步骤 1：增加最大合法边界测试**
+
+```rust
+#[test]
+fn test_maximum_aggregate_lengths_do_not_preallocate_declared_size() {
+    for frame in [
+        "*2147483647\r\n",
+        "%2147483647\r\n",
+        "~2147483647\r\n",
+        ">2147483647\r\n",
+    ] {
+        let mut parser = RespParse::new(RespVersion::RESP3);
+        assert_eq!(
+            parser.parse(Bytes::copy_from_slice(frame.as_bytes())),
+            RespParseResult::Incomplete,
+            "{frame:?}"
+        );
+    }
+}
+```
+
+- [ ] **步骤 2：运行 resp crate 完整测试**
+
+运行：`cargo test -p resp`
+
+预期：全部 PASS，现有正常、空、null、分片和 RESP3 聚合解析行为不变。
+
+- [ ] **步骤 3：运行静态检查**
+
+运行：`cargo clippy -p resp --all-targets -- -D warnings -D clippy::unwrap_used`、`cargo fmt --check`、`git diff --check`
+
+预期：三条命令退出码均为 0，无 warning、格式或 whitespace error。
+
+### 任务 4：同步项目状态并交付 PR
+
+**文件：**
+- 修改：`.planning/STATE.md`
+- 修改：`.planning/KANBAN.md`
+
+- [ ] **步骤 1：记录验证证据**
+
+把任务 3 的 exact 命令、环境、结果和最终 commit 写入 STATE/KANBAN；不得把尚未完成的 GitHub checks 写成通过。
+
+- [ ] **步骤 2：检查范围**
+
+运行：`git status --short`、`git diff --stat origin/main...HEAD`、`git diff origin/main...HEAD`
+
+预期：只有本计划“文件结构”列出的五个路径；无 Cargo、网络、认证、#402 文档或 Hot Tier 改动。
+
+- [ ] **步骤 3：提交并推送**
+
+提交信息：`fix(resp): bound aggregate parser allocations`
+
+- [ ] **步骤 4：创建独立 PR**
+
+PR base 必须是 `main`，正文引用 Issue #395 和 PR #402，但不得使用 `Closes #395`，因为本 PR 只处理其中 B1。