From 6fcb0981298b09c733ec66c6d57ebff654a0e238 Mon Sep 17 00:00:00 2001 From: garrytan Date: Wed, 30 Sep 2026 22:42:29 +0000 Subject: [PATCH] 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. --- plan-eng-review/sections/review-sections.md | 2 +- scripts/resolvers/testing.ts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/plan-eng-review/sections/review-sections.md b/plan-eng-review/sections/review-sections.md index 57c85f4eb..6bd368093 100644 --- a/plan-eng-review/sections/review-sections.md +++ b/plan-eng-review/sections/review-sections.md @@ -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) diff --git a/scripts/resolvers/testing.ts b/scripts/resolvers/testing.ts index 71c72d984..cac3e8a66 100644 --- a/scripts/resolvers/testing.ts +++ b/scripts/resolvers/testing.ts @@ -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(`