WEBVTT

1
00:00:00.000 --> 00:00:03.390
An agent's change can be partly
useful and still need correction.

2
00:00:03.773 --> 00:00:06.932
This lesson teaches you to
review each part against a brief,

3
00:00:07.082 --> 00:00:10.740
preserve the useful improvement,
and reject an unrelated edit.

4
00:00:11.018 --> 00:00:14.722
We will work on a feature branch so
that the proposal has a clear purpose

5
00:00:14.931 --> 00:00:17.079
and a clear relationship to the baseline.

6
00:00:17.462 --> 00:00:20.260
Start from a clean CP01 practice checkout.

7
00:00:20.341 --> 00:00:24.138
Inspect Git status, the current
branch, and recent history.

8
00:00:24.521 --> 00:00:28.979
If unexplained working edits exist,
preserve and account for them first.

9
00:00:29.304 --> 00:00:33.414
A branch names a line of recorded
development. It does not automatically

10
00:00:33.495 --> 00:00:37.710
hide or protect every uncommitted
change already in the working tree.

11
00:00:38.035 --> 00:00:41.135
Create the branch named
feature slash report-origin

12
00:00:41.576 --> 00:00:45.384
using the command in the lesson.
Confirm the resulting branch name.

13
00:00:45.662 --> 00:00:49.726
The name tells us what the task is about,
but it does not enforce the scope.

14
00:00:49.935 --> 00:00:54.289
The brief and review will do that.
If the branch already exists, inspect

15
00:00:54.323 --> 00:00:58.573
its state rather than inventing another
near-identical name to get past an error.

16
00:00:58.898 --> 00:01:02.950
Write a bounded request for a README
clarification that the baseline uses

17
00:01:02.996 --> 00:01:07.489
synthetic input. Permit only the
designated documentation paragraph.

18
00:01:07.872 --> 00:01:12.865
Preserve the host sample, firmware,
dependencies, and build commands. Ask

19
00:01:12.923 --> 00:01:17.392
the agent to show the diff and distinguish
checks actually run from proposed checks.

20
00:01:17.903 --> 00:01:21.073
This gives the resulting patch
a concrete acceptance boundary.

21
00:01:21.514 --> 00:01:23.604
Observe the actual agent actions.

22
00:01:23.987 --> 00:01:27.029
The assistant may produce
exactly the requested change.

23
00:01:27.308 --> 00:01:29.850
If so, preserve that result honestly.

24
00:01:30.094 --> 00:01:33.322
We will not pretend it made a
mistake for the camera. The course

25
00:01:33.345 --> 00:01:36.921
supplies a separate seeded review
candidate that deliberately contains

26
00:01:36.967 --> 00:01:40.299
an unrelated edit so everyone
can practice rejecting one.

27
00:01:40.683 --> 00:01:43.713
Keep the constructed-exercise
label visible when using it.

28
00:01:44.096 --> 00:01:48.148
The seeded candidate contains a
useful README sentence and a change

29
00:01:48.183 --> 00:01:52.421
in the host baseline's fixed synthetic
temperature from twenty-five to thirty.

30
00:01:52.746 --> 00:01:57.286
CP01 does not yet have a threshold
policy or the later fixture parser.

31
00:01:57.495 --> 00:02:00.444
This is a sample-value change
in the minimal host program.

32
00:02:00.769 --> 00:02:03.752
It is unrelated to a
documentation-only request,

33
00:02:04.031 --> 00:02:07.932
even though the program may still
compile and print valid-looking JSON.

34
00:02:08.257 --> 00:02:12.007
Inspect the changed-file list
before reading individual hunks.

35
00:02:12.390 --> 00:02:16.082
A README-only task touching
host source deserves attention.

36
00:02:16.466 --> 00:02:21.202
Then read each hunk in context.
Ask which requirement justifies it,

37
00:02:21.353 --> 00:02:24.825
what behavior it changes, and
which check would reveal a mistake.

38
00:02:25.150 --> 00:02:28.726
The number of added lines is not
a substitute for those questions.

39
00:02:29.109 --> 00:02:32.000
Accept the origin clarification
if it is accurate.

40
00:02:32.441 --> 00:02:36.273
Reject the host sample change because
the brief preserves that value

41
00:02:36.319 --> 00:02:40.580
and supplies no reason to alter it.
Your review note should name the file,

42
00:02:40.696 --> 00:02:44.237
the changed value, the consequence,
and the requested correction.

43
00:02:44.678 --> 00:02:48.324
Keep the README sentence, restore
the host sample to twenty-five,

44
00:02:48.498 --> 00:02:51.598
and rerun the applicable
replay after correcting source.

45
00:02:52.039 --> 00:02:56.578
This is a partial rejection, not a
verdict that the entire answer is useless.

46
00:02:57.089 --> 00:02:59.771
Separating the two
ideas preserves progress

47
00:03:00.014 --> 00:03:02.685
while keeping control of
the engineering decision.

48
00:03:03.126 --> 00:03:07.503
A useful future idea can be written
in a separate note, but it should not

49
00:03:07.573 --> 00:03:11.915
slip into the current task just because
it appeared beside a correct edit.

50
00:03:12.298 --> 00:03:16.547
Make the correction in the editor or
through the documented exercise procedure.

51
00:03:17.058 --> 00:03:21.772
Inspect the diff again. If a file
contains useful and unwanted changes,

52
00:03:22.097 --> 00:03:25.603
replacing the entire file from
baseline may discard good work.

53
00:03:26.044 --> 00:03:29.702
Use the smallest understandable
correction and verify its result.

54
00:03:30.213 --> 00:03:32.732
A blank diff achieved
by removing every change

55
00:03:32.767 --> 00:03:35.716
would fail because the requested
improvement would be gone.

56
00:03:36.319 --> 00:03:39.187
Run the relevant baseline
replay if source was touched.

57
00:03:39.512 --> 00:03:41.846
Check its actual output and exit result.

58
00:03:42.357 --> 00:03:45.433
The fixed sample should be
restored and explicitly synthetic.

59
00:03:45.712 --> 00:03:48.742
This verifies the affected
behavior in the host program;

60
00:03:49.021 --> 00:03:51.285
it does not establish physical operation.

61
00:03:51.795 --> 00:03:54.059
For the final pure documentation change,

62
00:03:54.210 --> 00:03:58.726
also read the paragraph in context and
confirm its wording matches the evidence.

63
00:03:59.678 --> 00:04:03.196
Stage and commit the reviewed candidate
with a purpose-focused message.

64
00:04:03.521 --> 00:04:06.366
Push the feature branch to
the verified private remote.

65
00:04:06.749 --> 00:04:11.045
Open a pull request with main as the base
and your feature branch as the comparison.

66
00:04:11.486 --> 00:04:14.203
Inspect those branch
selections before creation.

67
00:04:14.586 --> 00:04:17.640
A pull request aimed at the
wrong base can show a confusing

68
00:04:17.721 --> 00:04:20.380
diff even when your local task is small.

69
00:04:20.983 --> 00:04:25.372
Open Files changed and compare the hosted
proposal with the final local diff.

70
00:04:25.813 --> 00:04:28.414
The intended README
improvement should be present,

71
00:04:28.623 --> 00:04:31.386
and the unrelated host
value should be unchanged.

72
00:04:31.769 --> 00:04:34.950
The review surface organizes
discussion and checks;

73
00:04:35.276 --> 00:04:38.190
it is not an automatic
certification of correctness.

74
00:04:38.631 --> 00:04:40.686
If you review your own practice proposal,

75
00:04:40.860 --> 00:04:44.493
call it a self-review rather than
claiming another person approved it.

76
00:04:45.004 --> 00:04:48.592
Write the description for someone
who has not seen your conversation.

77
00:04:49.033 --> 00:04:53.631
Name the reporting ambiguity, the new
explicit synthetic-origin wording,

78
00:04:53.805 --> 00:04:56.011
and the validation actually performed.

79
00:04:56.452 --> 00:05:00.468
Do not include abandoned suggestions
unless they explain a relevant tradeoff.

80
00:05:00.852 --> 00:05:04.102
Do not list tests as passed if
you only proposed running them.

81
00:05:04.427 --> 00:05:08.270
A concise, accurate description makes
the reviewer’s next action clear.

82
00:05:08.595 --> 00:05:12.079
For your exercise, submit the
review note, corrected diff,

83
00:05:12.172 --> 00:05:15.480
applicable replay result, and
private pull-request reference.

84
00:05:15.759 --> 00:05:18.035
If account access
prevents the remote step,

85
00:05:18.209 --> 00:05:20.682
keep it pending while
completing the local review.

86
00:05:21.007 --> 00:05:24.350
The local diff cannot serve as
evidence that a pull request exists.

87
00:05:24.675 --> 00:05:27.462
Each action keeps its
own observable result.

88
00:05:27.903 --> 00:05:31.653
A review finding should survive being
separated from the conversation.

89
00:05:32.094 --> 00:05:35.705
Include the relevant path,
old and new value, requirement,

90
00:05:35.728 --> 00:05:38.758
and requested correction.
Another contributor can then

91
00:05:38.851 --> 00:05:41.986
act on it without guessing what
you meant by the extra change.

92
00:05:42.369 --> 00:05:45.527
When the correction arrives,
inspect the new diff rather than

93
00:05:45.562 --> 00:05:48.894
approving it because the author
says the issue is resolved.

94
00:05:49.219 --> 00:05:53.131
The evidence for resolution is the
revised content and relevant check,

95
00:05:53.456 --> 00:05:57.717
not the acknowledgment. You are ready to
continue when the useful change remains,

96
00:05:57.926 --> 00:06:01.630
the unrelated edit is gone,
and your evidence explains why.

97
00:06:02.326 --> 00:06:06.517
The next lesson introduces a deliberate
text conflict and two different recovery

98
00:06:06.575 --> 00:06:10.731
operations. We will keep their starting
states separate so that resolving meaning,

99
00:06:10.940 --> 00:06:14.888
discarding an unwanted working edit,
and reversing a committed fault do not

100
00:06:14.934 --> 00:06:17.790
become one vague instruction
to undo everything.