Runtime Log Review（日志阅读）
读项目运行时日志（前端 + 后端），产出给人看的 日志阅读.md。
When to use
- 用户说：看日志 / 日志阅读 / 功能测完了 / 哪些功能正常哪些有问题
- 需要把终端、日志文件、控制台输出整理成测试结论
Workflow
Copy and track:
Log review:
- [ ] 1. Locate log sources
- [ ] 2. Collect recent runtime output
- [ ] 3. Map to features / scenarios
- [ ] 4. Classify OK vs FAIL
- [ ] 5. Write 日志阅读.md
- [ ] 6. Tell user the file path + short summary
1. Locate log sources
Discover in this order (use what exists; ask only if nothing found):
- Agent terminals — recent
npm/pnpm/yarn/vite/next/uvicorn/django/spring/docker composeoutput - Project log files — common paths:
logs/,log/,*.log,backend/logs/,frontend/logs/,storage/logs/,.next/,tmp/ - User-provided paths — if they paste a path or file, prefer that
- Browser / frontend — DevTools console export, network error text, or FE terminal (Vite/Webpack HMR errors)
Prefer time window of this test session (last run). Ignore ancient rotated logs unless user asks for history.
2. Collect
- Pull enough context around each error (stack + nearby request/route/component name)
- Keep verbatim error messages for the report (do not invent)
- Note timestamps / request ids when present
- If logs are huge: grep for
error,Error,ERROR,Exception,failed,FATAL,warn(only promote warn when it blocks a feature)
3. Map to features
Infer feature names from:
- Route / API path / screen name / test case title the user listed
- Log tags / module names
- If unclear: use the closest identifiable unit (e.g.
POST /api/login,CheckoutPage) and mark mapping confidence as 推断
If the user gave a feature checklist, cover every item. Unmentioned-but-broken areas go under「未在清单中但发现的问题」.
4. Classify
| Status | Rule |
|---|---|
| 正常 | No error for that feature in the collected window; or explicit success signals |
| 异常 | Error/exception/failed assertion tied to that feature |
| 未验证 | No log evidence either way |
Do not mark 正常 just because the process is still running. Need absence of related errors or positive success evidence.
5. Write report
- Default path: project root
日志阅读.md(overwrite only this report file; if one exists, replace with a fresh run and put previous date in「报告信息」) - If user gives another path/name, use theirs
- Use the template in report-template.md verbatim structure (section order and headings)
- Fill every section; use
无when empty - Errors: quote original text in fenced code blocks; truncate middle of ultra-long stacks with
...but keep first/last meaningful frames
6. Reply to user
After writing the file:
- Path to
日志阅读.md - Counts: 正常 / 异常 / 未验证
- Top 3 failures (one line each) if any
Rules
- Evidence from logs only — no guessing root cause as fact; hypotheses go under「可能原因（推断）」
- Frontend and backend both required when both ran; if only one side exists, say so in「覆盖范围」
- Chinese report body (feature names may stay as in product/code)
- Do not commit the report unless user asks
