An assistant proposes a two-line RTL fix. Before discussing the fix, identify the baseline: which revision is checked out, which files were already modified, and which checks are expected to pass? An AI-generated patch is not special; it needs the same ownership, review and verification as a human patch. Existing work from a colleague must not be discarded to make the assistant's change easier.
Synthetic review record
baseline: revision r3; existing unrelated edits in notes/design-review.md
task: explain a width warning in rtl/counter.sv
allowed action: read and propose only
proposal: one diff plus the requirement it implements
acceptance: reviewed scope, independent corner checks, explicit human approval
not allowed: change tests to hide failure, update unrelated files, commit or publishA branch names a line of development; it is not a filesystem sandbox. A separate working copy or worktree helps avoid mixing edits but also does not restrict credentials or network access. Use the organisation's approved isolation and execution tools. Start this course's labs with read-only proposals so Git mechanics do not obscure the engineering task.
Review question | What to inspect |
|---|---|
Is this the expected baseline? | Revision, tool configuration and pre-existing changes. |
Is the diff limited to the task? | All changed files, including tests, constraints, waivers and generated files. |
Does the patch implement the requirement? | Width, reset, protocol and corner behaviour; smaller is not automatically correct. |
Were checks weakened? | Deleted assertions, skipped tests, added suppressions or altered expected values. |
What remains unverified? | Evidence of checks actually run, their inputs and limits. A suggested command is not an executed check. |
The requested fix concerns one counter expression. The diff also deletes a failing test and adds a lint waiver. Write a review response that identifies the extra changes without assuming malicious intent. Ask for the requirement and a reduced proposal. Preserve unrelated existing edits.
A scoped diff implementing the stated behaviour, unchanged independent checks or justified reviewed changes to them, and actual check results. Reject the waiver and test deletion as unsupported until independently justified. Never reset somebody else's working tree as cleanup.
Optional reading: the Git diff documentation explains comparisons between working-tree, staged and committed content. Your team's branch, review and publication rules remain authoritative.