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:
garrytan committed 2026-09-30 22:42:29 +00:00
1 parent d0c5357763
commit 6fcb098129
2 files changed
+2 -2

No files matched your search

+1 -1
View File
@@ -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: 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: 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) - Where does input come from? (request params, props, database, API call)
- What transforms it? (validation, mapping, computation) - What transforms it? (validation, mapping, computation)
+1 -1
View File
@@ -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:`; 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' 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.`; : `1. **Read the diff.** For each changed file, read the full file (not just the diff hunk) to understand context.`;
sections.push(` sections.push(`