aws-case-drafter 0.1.0__tar.gz

aws_case_drafter-0.1.0/.gitignore

@@ -0,0 +1,34 @@
+# Python
+__pycache__/
+*.py[cod]
+*$py.class
+*.so
+*.egg-info/
+*.egg
+dist/
+build/
+
+# Virtual environments
+.venv/
+venv/
+ENV/
+
+# Testing
+.hypothesis/
+.pytest_cache/
+.coverage
+htmlcov/
+
+# IDE
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Environment variables
+.env
+.env.local

aws_case_drafter-0.1.0/.kiro/backlog.md

@@ -0,0 +1,96 @@
+# Backlog（候选改进池）
+
+仓库级的未来改进候选池，跨 spec、未排期。条目要正式开工时，把它「毕业」成 `.kiro/specs/<feature>/` 下的独立 spec，再从这里移除或标记。
+
+> 注：这里只记「想做什么 + 为什么 + 大致路径」，不是实现计划。MVP 范围内的已排期任务在各自 spec 的 `tasks.md`。
+
+---
+
+## Lambda 日志查询灵活化（非报错类问题）
+
+- 问题：`fetch_lambda_context` 当前是「错误日志专用」——`fetch_lambda.py` 写死了一个错误关键字
+  filter pattern（`ERROR/Exception/Failed/timeout/Runtime.`），`logs.py` 又围绕「匹配到的错误行
+  → 按 RequestId 补全 START/END/REPORT 生命周期」组织。对**不报错的问题**抓不到相关日志：
+  - 不报错但行为异常（结果不对、走错分支、该触发没触发）
+  - 性能/冷启动（只想看 REPORT 行的 Duration/Init Duration，没有 ERROR 关键字）
+  - 特定业务标识（订单号/下游服务名如 DynamoDB，想按它捞）
+  - 特定时间点（事故发生在过去某个具体时刻，而非「最近 N 小时」）
+- 思路：把日志查询的部分控制权交给模型，但**不暴露 CloudWatch 原生 filter 语法**（大小写敏感、
+  `?"..."` OR 语法，弱模型必写错），改成几个直观可选参数，服务端翻译成正确 pattern。
+- 建议参数（全部可选、向后兼容，不填即现状）：
+  - `keyword: str | None = None` —— 简单关键字，非空时围绕它构建匹配（服务端处理大小写变体），
+    取代默认错误过滤。
+  - `latest_stream_only: bool = False` —— True 时跳过错误过滤，直接拉**最新 log stream 的全部日志**
+    （「不报错、想看函数到底在干嘛」的场景）。
+  - `end_time: str | None = None`（ISO8601）—— 时间窗变成 `[end_time - window, end_time]`，
+    处理过去某时刻的事故；不填默认 now（即现状）。优先级：可后置，先上前两个也够用。
+  - 优先级：`latest_stream_only` > `keyword` > 默认错误过滤。
+- 注意点：
+  - 关键字/最新流模式**不能套用 RequestId 生命周期补全**（那是为错误行设计的），走「原样返回」
+    路径（类似现有 `with_context=False`）。
+  - `latest_stream_only` 需先 `describe_log_streams` 拿最新 stream，再 `get_log_events`，
+    和现有 `filter_log_events` 路径不同，需在 `logs.py` 加新查询函数。
+  - redaction、50k 截断、`hints.instructions`（「不要分析总结日志」）原样保留。
+- 影响：`fetch_lambda.py`、`logs.py`、`validation.py`（新参数校验）+ 测试。medium effort。
+
+---
+
+## Lazy credential re-check（凭证模式自愈）
+
+- 问题：`credential_mode` 在启动时决定一次后冻结。启动时的瞬时失败（如慢 AssumeRole profile
+  超时）会把 server 永久降级为 credentialless 直到重启，即便 AWS 已恢复。
+- 修复：credentialless 模式下，若工具调用未显式带 `aws_profile`，在调用时尝试解析一次凭证；
+  成功则升级为 credential 模式并缓存 session。
+- 影响：`AppContext` 和 `fetch_lambda` 的 session 获取；medium effort。
+- 现状缓解：已把 `_CREDENTIAL_TIMEOUT_SECONDS` 放宽到 15s。
+
+---
+
+## 超大文本内容转附件上传（日志 / 目录 / 配置）
+
+- 目标：当要附加的信息过大（用户想贴大量日志/目录/多文件，或 fetch 工具抓到大段日志）时，
+  自动检测并把内容打包压缩成附件上传，避免塞爆工单正文、也省去客户手动操作。
+- 选这个角度（而非截图）的原因：这类内容是**工具本就持有的文本**，不存在截图那种「用户粘进
+  聊天框的字节进不了 MCP 工具调用」的死结，实现路径直接、可控。截图方案因字节传递难题暂搁置。
+- 检测机制（核心）：
+  - 设阈值（如正文超过 N KB / 日志行数超过 M / 多个文件），触发「转附件」决策。
+  - 正文里保留**关键摘要 + 代表性片段**（含 RequestId、INIT、REPORT、首末错误行），完整内容
+    进附件，符合现有「日志要有上下文」原则，避免正文被淹没。
+- 压缩：多文件/目录 → zip；单个大日志 → gzip 或直接 .txt（视 5MB 限制）。
+- API path：`add_attachments_to_set` → `attachmentSetId` → `create_case(attachmentSetId=...)`
+  或 `add_communication_to_case(attachmentSetId=...)`。
+- Support API 限制：单集最多 3 个附件、单个 ≤5MB、attachment set 创建后 1 小时过期；需 Business+
+  Support Plan。aws-cn 同样支持（端点仍为 `support.cn-north-1`）。超 5MB 需切分/进一步压缩；
+  超 3 个需合并打包。
+- 安全：附件内容同样要过现有 `redaction` 脱敏后再压缩上传。
+- 设计建议：在 `draft_support_case` 阶段就标记「内容过大、建议转附件」，`submit_support_case`
+  增加可选 `attachments` 参数（内容/路径列表），内部走 attachment set 流程。
+- 优先级：比截图方案更实际、价值更高。medium effort。
+
+---
+
+## fetch → draft 上下文服务端中转（不依赖模型转发）
+
+- 问题：fetch_* 的真实输出靠模型手动塞进 `draft_support_case` 的 `collected_context` 参数转发，
+  弱模型（DeepSeek/千问，Cherry Studio 实测）不稳定，会重写/改名/丢字段/凭空编造：
+  - 实测一次：fetch 把大量日志**转储为附件文件**返回，模型没看到日志内容，于是编了假的
+    `error_logs_sample`（时间戳都是错的），还把真实附件路径 `attachment_files`/`logs_file` 丢了。
+  - 后果：draft 生成的工单**既无内联日志、也无附件**，日志彻底丢失，正文只剩 `[请补充: 错误日志]` 占位符。
+  - 复现脚本：`demo/repro_draft.py`。注：模型不稳定，重跑有时正常，非必现。
+- 根因：模型是 fetch→draft 之间传数据的薄弱环节，靠 prompt 要求「原样传入」对弱模型不可靠。
+- 修复（服务端 registry 中转，沿用 attachments / case-lock 已有模式）：
+  - 在 `dedup.py`（或 attachments.py）加一个 per-session **fetch-context registry**，按
+    `normalize_case_key(资源标识)` 存储 fetch 的真实输出。
+  - fetch_* 收集完后把真实 `data` 写入该 registry（不依赖模型）。
+  - `draft_support_case` 按 `incoming_key` 取回，**盖在模型传的 collected_context 之上**
+    （真实 error_logs / attachment_files / logs_file / function_arn 等覆盖模型编造的）。
+  - 清理：提交成功后在 `reset_case_state()` 一并清空。
+- **累积语义（关键，处理多次 fetch）**：registry 按资源 key 存但**合并而非覆盖**——
+  模型可能用不同 `time_window_hours`（如先查12点、再查5点）多次 fetch，参数不同 → dedup 不拦 → 各自产出一个日志文件：
+  - `attachment_files`：取并集（所有批次的日志文件都作为附件上传，一条不丢）
+  - `error_logs`（内联）：合并 + 按 (timestamp, message) 去重；合并后若超阈值可考虑重新转储（锦上添花，可后置）
+  - `function_arn`/`region` 等标识：取最新非空
+  - 注：draft 锁定后 fetch 会短路（already_drafted），所以多次 fetch 只发生在收集阶段，累积才是正确语义。
+- 影响：`dedup.py`（新 registry）、`fetch_lambda.py` / `fetch_apigw.py`（写入）、
+  `draft_case.py`（取回+覆盖）+ 测试。medium effort。
+- 优先级：高。这是工单内容质量的核心可靠性问题，但 demo 阶段模型表现尚可，故排期到 demo 之后。

aws_case_drafter-0.1.0/.kiro/hooks/auto-build-whl.kiro.hook

@@ -0,0 +1,14 @@
+{
+  "enabled": true,
+  "name": "Auto Build Wheel",
+  "description": "每轮 Kiro 执行结束后构建一次 whl 包到 dist/（仅当 src/ 有改动时），避免单轮多次构建",
+  "version": "2",
+  "when": {
+    "type": "agentStop"
+  },
+  "then": {
+    "type": "runCommand",
+    "command": "cd /home/ec2-user/kiro/case-drafter && newest=$(ls -t dist/*.whl 2>/dev/null | head -1); if [ -z \"$newest\" ] || [ -n \"$(find src -name '*.py' -newer \"$newest\" 2>/dev/null)\" ]; then uv build; else echo 'skip build: src 无改动'; fi",
+    "timeout": 60
+  }
+}

aws_case_drafter-0.1.0/.kiro/hooks/auto-git-commit.kiro.hook

@@ -0,0 +1,13 @@
+{
+  "enabled": true,
+  "name": "Auto Git Commit",
+  "description": "每次 Kiro 完成执行后，自动将所有变更 git commit（如果有变更的话）",
+  "version": "1",
+  "when": {
+    "type": "agentStop"
+  },
+  "then": {
+    "type": "runCommand",
+    "command": "cd /home/ec2-user/kiro/case-drafter && git add -A && git diff --cached --quiet || git commit -m \"auto: $(git diff --cached --stat | tail -1)\""
+  }
+}

aws_case_drafter-0.1.0/.kiro/settings/mcp.json

@@ -0,0 +1,15 @@
+{
+  "mcpServers": {
+    "aws-case-drafter": {
+      "command": "/home/ec2-user/kiro/case-drafter/.venv/bin/aws-case-drafter",
+      "env": {
+        "AWS_REGION": "cn-north-1"
+      },
+      "disabled": true,
+      "autoApprove": [
+        "fetch_lambda_context",
+        "draft_support_case"
+      ]
+    }
+  }
+}

aws_case_drafter-0.1.0/.kiro/specs/mvp-mcp-tools/.config.kiro

@@ -0,0 +1 @@
+{"specId": "689e6757-998e-4b46-b746-e0c4ec399c7a", "workflowType": "requirements-first", "specType": "feature"}