mirror of
https://github.com/garrytan/gstack.git
synced 2026-10-03 18:06:54 +02:00
fix(plan-eng-review): show the accepted dedicated read form for coverage-diagram sources
CI plan-eng-coverage-audit mixed package/config and git diff into the source read; the review variant, whose prompt shows the && display form, does not. The plan trace step now shows it too, within the unchanged size cap.
This commit is contained in:
1 parent
d0c5357763
commit
6fcb098129
2 files changed
+2
-2
No files matched your search
@@ -585,7 +585,7 @@ Test step 2 adds user flows. Future paths remain proposals, not runnable code.
|
||||
|
||||
Read the plan document. For each new feature, service, endpoint, or component described, trace how data will flow through the code — don't just list planned functions, actually follow the planned execution:
|
||||
|
||||
1. **Read the plan.** For each planned component, understand what it does and how it connects to existing code. When grounded in concrete source and test files, read them in a dedicated tool call before drawing the diagram. Do not mix diff, grep, package/config, git, or commentary into that read; use separate calls for context. Base the diagram on that read.
|
||||
1. **Read the plan.** For each planned component, see how it connects to existing code. When grounded in concrete source and test files, read them in a dedicated tool call before drawing the diagram (`cat -n src/f && echo -- && cat -n test/f`). Do not mix diff, grep, config, git or commentary into that read; use separate calls for context. Base the diagram on that read.
|
||||
2. **Trace data flow.** Starting from each entry point (route handler, exported function, event listener, component render), follow the data through every branch:
|
||||
- Where does input come from? (request params, props, database, API call)
|
||||
- What transforms it? (validation, mapping, computation)
|
||||
|
||||
@@ -304,7 +304,7 @@ Read the plan document. For each new feature, service, endpoint, or component de
|
||||
Read every changed file. For each one, trace how data flows through the code — don't just list functions, actually follow the execution:`;
|
||||
|
||||
const traceStep1 = mode === 'plan'
|
||||
? `1. **Read the plan.** For each planned component, understand what it does and how it connects to existing code. When grounded in concrete source and test files, read them in a dedicated tool call before drawing the diagram. Do not mix diff, grep, package/config, git, or commentary into that read; use separate calls for context. Base the diagram on that read.`
|
||||
? `1. **Read the plan.** For each planned component, see how it connects to existing code. When grounded in concrete source and test files, read them in a dedicated tool call before drawing the diagram (\`cat -n src/f && echo -- && cat -n test/f\`). Do not mix diff, grep, config, git or commentary into that read; use separate calls for context. Base the diagram on that read.`
|
||||
: `1. **Read the diff.** For each changed file, read the full file (not just the diff hunk) to understand context.`;
|
||||
|
||||
sections.push(`
|
||||
|
||||
Reference in new issue
Block a user