Review the implementation plan before coding

Make the proposed path reviewable before the first edit

The problem, scope, and proof of “done” are already bounded. One common failure remains: an AI or teammate produces a plan that sounds coherent, but the plan has missed a dependency, treated a proposed change surface as certain, or postponed verification until after the expensive edits are already made. If you start coding immediately, the first real review of direction happens after a diff exists.

In this lesson you build Plan Review Record v1: a compact review artifact that shows, for each proposed step, what scope item or acceptance criterion it primarily traces to, which relevant specification constraints must be checked as secondary annotations, what change surface it expects, which dependency or unknown matters, which assumption/risk needs evidence, and how the step will be verified. A human then records ACCEPT, MODIFY, or REJECT for the specific plan, with a reason.

This lesson does not rewrite the specification and it is not code review. It also does not assemble the full implementation-ready handoff; it critiques one proposed implementation plan before coding begins.

Approximate active time: 45 minutes.

This lesson is for you if: you tend to move directly from specification to implementation, or accept a proposed plan because it looks organized, technical, and confident.

This lesson is not for: rewriting the Problem Brief, Scope Box, or Done Matrix; editing code before a plan gate; treating a proposed file list as fixed scope; reviewing an already-created diff; or assembling the final end-to-end implementation handoff.

Hard prerequisite — FND-001-P03: you must be able to construct Done Matrix v1 so that criteria, proof methods, and evidence state are judgeable without depending on the implementation plan.

Short prerequisite probe

Case: after a file upload attempt, that attempt’s success or failure must be observable to the user. The storage provider must not change.

Write two short Done Matrix rows: one for success and one for failure. For each row state an observable criterion, proof method, and initial evidence state. Then add one separate line for the constraint “storage provider does not change,” with an appropriate proof method and initial evidence state. Do not propose a plan or files yet.

PASS requires 5/5: criteria describe behavior rather than implementation; proof method is distinct from criterion; success/failure are independently judgeable; the storage-provider constraint has a specific proof method; and all pre-execution evidence remains NOT_RUN rather than assumed PASS.

If one item fails, repair only that part in FND-001-P03 and repeat the probe. A strong plan cannot compensate for an ambiguous definition of Done.

Choose the amount of support you need

Every route ends at the same Plan Review Record v1 and the same evidence bar. Only the scaffolding changes.

Four-concept route probe

Answer briefly without reading ahead:

1. Implementation plan: why may a plan not create new scope or acceptance criteria?
2. Change surface: why is “these three files definitely change” usually weaker than “these surfaces are currently proposed and must be checked against repository evidence”?
3. Plan assumption and risk: how is a decision-driving assumption different from a fact, and what must happen before approval?
4. Plan review gate: why is an AI-generated plan not its own acceptance authority, even when it looks precise?

4/4 → experienced/Fast Path; 2–3/4 → repair only failed distinctions; 0–1/4 → foundation route.

• Foundation: use the full scaffold on the shared task-list case.
• Repair: rebuild only the fragile concept distinction.
• Experienced / Fast Path: jump to the independent case, which intentionally includes contradiction, unknown state, and dependency ambiguity.

Fast Path removes guidance, not evidence requirements.

Mental model: a plan is a change hypothesis, not the contract

Plan Review Record v1 sits between specification and edit. The specification says what behavior and boundary must hold; the plan says what technical path is currently proposed to realize them. That proposal must remain rejectable and revisable.

A good plan does not need to be long. For each step, another reviewer should be able to ask: why does this step exist, what might it touch, what is still unknown, and what check occurs before or after it?

The four foundation concepts

1. Implementation plan

An implementation plan is the proposed change map before editing code: steps, order, likely surfaces, and verification. It may not manufacture a requirement. Each step should primarily trace to an existing scope item or acceptance criterion and remain removable, reorderable, or revisable. Relevant specification constraints may be recorded as secondary checks or annotations; they do not replace the required scope/criterion trace. Do not convert a constraint into an invented criterion.

2. Change surface

The change surface is a technical, provisional picture of places the plan may affect: UI, service, data contract, configuration, tests, or files. Record READ/WRITE and confidence/unknown where useful. If repository discovery reveals another necessary surface, revise the plan; do not stretch scope to preserve the original file list.

3. Plan assumption and risk

An assumption is a claim the plan relies on without enough evidence; a risk is a possible consequence if that assumption or plan choice is wrong. Give each decision-driving assumption evidence needed, and each material risk a mitigation/check. “Probably true” is not closure.

4. Plan review gate

Before edits begin, a human compares the plan to the current specification and records one of three decisions:

• ACCEPT: current evidence supports starting from this plan;
• MODIFY: the direction may work, but a step/surface/assumption/check must change;
• REJECT: the plan materially conflicts with specification or evidence.

Record the reason and the reviewed spec/plan versions. This gate is not code review; code review inspects the actual diff later.

Build Plan Review Record v1

Your inputs are the existing Problem Brief v1, Scope Box v1, Done Matrix v1, and one proposed implementation plan. Do not merge them into a new mega-spec. Use them to review the plan.

For each step, record:

At artifact level, record the reviewed specification version and plan version, then end with Overall decision = ACCEPT/MODIFY/REJECT + reason.

Four construction rules:

1. Trace every step. Primary Trace must point to a scope item or acceptance criterion. Record relevant specification constraints separately as secondary checks/annotations; a constraint alone does not satisfy the required primary Trace. A step with no valid scope/criterion trace is a candidate for removal or explicit justification.
2. Keep surface hypothetical. A proposed file/component list is valid only as far as repository evidence supports it.
3. Keep unknowns alive. If ownership or dependency behavior is unresolved, do not approve a plan that silently guesses it.
4. Define verification before edits. Checks should show that the step advances a criterion without hiding a relevant regression.

AI may critique the plan, suggest candidate dependencies, or surface inconsistencies. It may not convert unknowns into facts, change locked scope, or replace the human gate.

Worked case: reviewing the unfinished-task filter plan

Packet identity: spec_version=TASK-SPEC-01 and plan_version=TASK-PLAN-01.

The existing specification says the user can switch between all tasks and unfinished only; completed tasks disappear in unfinished view; storage schema does not change; filter persistence and a page redesign are outside scope. The Done Matrix already defines proof for the display behavior, the return to All, and the schema constraint.

An AI proposes:

1. filter the fetched task list in the UI;
2. keep filter state in the component;
3. do not touch the data layer because task status already exists;
4. add one UI test for unfinished view.

The plan sounds reasonable, but review asks a direction-changing question: does filtering after fetch interact correctly with current pagination? If the backend returns 20 items per page, client-side filtering could produce an empty page even when unfinished tasks exist on a later page. The packet has not yet established the data-flow order.

A compact review record:

Overall decision: MODIFY. The direction is plausible, but the pagination assumption is decision-driving and must be resolved before edit. If evidence later supports a different surface, revise the plan and trace the new surface back to the same specification rather than enlarging scope.

Four plausible failures

Failure 1: plan steps do not trace to the specification

“Refactor the service” or “add a cache” may sound technical but can create new work. Repair: give every step a primary scope-item or acceptance-criterion trace. Record relevant specification constraints as secondary checks/annotations, not substitutes for that trace; without a valid primary trace, remove the step or justify it explicitly.

Failure 2: the file list becomes a contract

“Only these three files change” creates false certainty before repository discovery. Repair: mark surfaces as proposed, record READ/WRITE and confidence, and keep discovery allowed.

Failure 3: an assumption enters the plan as fact

“This service is synchronous” can control step order without evidence. Repair: record the assumption, evidence needed, and its review consequence. A decision-driving unresolved assumption requires MODIFY.

Failure 4: the plan is judged by plausibility instead of the spec

A polished plan can still contain scope expansion or weak verification. Repair: review against the Problem Brief, Scope Box, and Done Matrix—not architectural taste or confidence in the tool that wrote the plan.

Experienced bridge: when evidence does not agree with the plan

Real repositories often produce mixed signals before implementation. A comment may describe client-side behavior while an integration test suggests server-side filtering; a cache or event contract may exist but its owner is unclear. The reviewer’s job is not to pick a story by intuition. Preserve the contradiction in the record and state which step cannot be accepted until evidence resolves it.

For experienced practice, add three pressures:

• a dependency whose existence is known but exact contract is unknown;
• two evidence items that imply different change surfaces;
• a step whose premature execution would create an expensive diff or difficult rollback.

In these cases MODIFY or REJECT is not failure. The gate exists to prevent edits based on manufactured certainty.

Different plan formats and their trade-offs

A plan may be a checklist, table, short sequence, or issue breakdown. Format is secondary; invariants matter.

• Short checklist: fast for a small change, but trace and assumptions are easy to hide.
• Traceability table: strong for independent review, but can be heavy for trivial work.
• Dependency-first sequence: exposes ordering risk, but can drift into architecture planning if scope trace is missing.
• AI-generated prose plan: quick, but confident language can conceal unknowns and surface hypotheses.

Plan Review Record v1 does not replace every plan format. It applies four review questions to any format: trace? surface? assumption/risk? human gate?

Guided and independent practice

Guided case — Order search

Packet identity: spec_version=ORD-SPEC-03 and plan_version=ORD-PLAN-01.

Specification packet:

• in scope: find an order by full order number on the orders page;
• constraint: order schema does not change;
• out of scope: fuzzy search, customer-name search, redesign;
• Done: exact match is visible, no-match is explicit, and the existing orders-list path remains intact.

Proposed plan:

1. add a search input to the page;
2. add an exact-order-number query;
3. render match/no-match state;
4. run a match/no-match smoke test.

Review it. Which steps trace? Is the query layer a proven change surface or only a proposal? What evidence is required before claiming no current endpoint can perform exact lookup? Issue ACCEPT, MODIFY, or REJECT with a reason.

Independent case — Fast Path destination: Avatar refresh

Packet identity: spec_version=AVATAR-SPEC-02 and plan_version=AVATAR-PLAN-07.

Specification packet:

• in scope: after a successful avatar replacement, the new image is visible on the next profile visit;
• constraint: upload API contract and storage provider do not change;
• out of scope: crop editor, avatar history, profile redesign;
• Done criteria: success exposes the new image; failure preserves the current image and shows a clear error; API/storage contract remains unchanged.

Proposed plan:

1. after success, render the current avatar URL with a new query token;
2. remove the client cache entry;
3. make no server/CDN change;
4. verify success/failure and the next profile visit.

Evidence packet:

• repository note A: the profile client has a local cache for image URLs;
• operations note B: “some avatars remain behind CDN cache and invalidation may be required”;
• API contract: upload returns a URL, but TTL/cache ownership is not specified in this packet;
• dependency state: cache behavior and ownership across client/CDN are unknown, and the two notes have not been reconciled.

Build Plan Review Record v1. Preserve the contradiction and unknown explicitly. Do not guess whether client-only or CDN-only is correct. Any step that relies on that assumption must remain CHANGE/unresolved, and the overall gate remains MODIFY—or REJECT if you find a fundamental conflict—until sufficient evidence exists. State one bounded pre-edit check that could resolve the ambiguity.

Verification: when is the review record strong enough?

Before approval, answer five questions:

1. Does every plan step trace to a specific scope item or criterion?
2. Are proposed surfaces marked with READ/WRITE and confidence/unknown instead of being presented as fixed scope?
3. Do decision-driving assumptions have evidence-needed, and material risks have mitigation/checks?
4. Is verification defined before editing and aligned with the Done Matrix?
5. Has a human recorded ACCEPT/MODIFY/REJECT, the reason, and the reviewed spec/plan versions?

If a critical answer is no, approval is premature. Machine checks or AI critique may help with consistency, but artifact sufficiency and the gate remain human judgments.

Assessment and transfer

By the end, you should be able to take a fresh change request and, without a prefilled template:

• trace a proposed plan to its specification;
• record proposed read/write surfaces and unknowns;
• separate assumptions/risks from facts;
• define verification before edits;
• and issue a reasoned human gate.

Transfer is not copying the task-list wording. The same invariants must survive in another domain.

Boundary to the next lesson: this lesson reviews one plan. The next stage integrates prior decisions into one implementation-ready handoff and audits the package’s traceability and ambiguity. Do not build that integrated handoff here.

References and freshness

The authority for this lesson’s title, artifact, four concepts, and neighbor boundary is the locked curriculum specification. Standards and tool documentation are context and sanity checks; they do not define the Plan Review Record v1 format.

On 5 September 2026, ISO/IEC/IEEE 29148:2018 remained the published Edition 2 and current edition, while marked for revision; Edition 3 remained a Draft International Standard under development. Live coding-agent documentation also continues to evolve around planning, task scoping, review, and verification. For that reason, this lesson does not teach any product-specific mode, command, or guarantee as an engineering law.

If a future revision adds a current tool or standard-status claim, recheck the exact source immediately before publication.