36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
## Context
|
|
|
|
The current `mvp/demo` folder documents the core flow, but the steps are embedded in prose. For an interview, the demo needs a sharper entry point: what to start, what to run, what files get produced, and what to point at when explaining Agent engineering quality.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Make the payment-timeout demo runnable through a small script.
|
|
- Save chat, trace, and feedback responses for review.
|
|
- Provide a short interview walkthrough that connects runtime evidence to the engineering story.
|
|
- Keep the demo focused on existing APIs and existing `mvp-demo` profile behavior.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Do not add new backend endpoints.
|
|
- Do not modify Agent prompts or runtime orchestration.
|
|
- Do not solve secret cleanup or full offline test isolation in this change.
|
|
- Do not expand the eval harness.
|
|
|
|
## Decisions
|
|
|
|
- Decision: Use PowerShell scripts.
|
|
- Reason: the current runbook already uses PowerShell and the user environment is Windows.
|
|
|
|
- Decision: Save outputs under `mvp/demo/output`.
|
|
- Reason: interview review is easier when chat, trace, and feedback responses are persisted as files.
|
|
|
|
- Decision: Keep the walkthrough separate from the low-level runbook.
|
|
- Reason: `README.md` should tell how to run; `interview-walkthrough.md` should tell how to explain.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- The demo still depends on configured MySQL, Redis, Milvus, and model keys. Mitigation: document this explicitly and keep mock log/metric providers enabled through `mvp-demo`.
|
|
- Script assertions are intentionally lightweight. Mitigation: use the trace checklist for human review and keep automated regression in `mvp/eval`.
|