WEBVTT

1
00:00:00.000 --> 00:00:04.040
A good engineering brief makes success
visible before an assistant starts work.

2
00:00:04.365 --> 00:00:07.837
It does not need special magic
wording. It needs a clear goal,

3
00:00:07.953 --> 00:00:10.646
a known starting state,
the information that affects

4
00:00:10.681 --> 00:00:14.222
the decision, and checks that tell
us whether the result is acceptable.

5
00:00:14.826 --> 00:00:18.750
In this lesson we will transform a vague
sensor request into a small reporting

6
00:00:18.796 --> 00:00:23.510
task. The initial request says, fix
my sensor, the output looks wrong,

7
00:00:23.591 --> 00:00:26.714
and clean things up too. You
may know what that means because

8
00:00:26.737 --> 00:00:30.441
you have been looking at the project
all morning. The assistant does not know

9
00:00:30.487 --> 00:00:32.891
which behavior is wrong,
which files are current,

10
00:00:32.949 --> 00:00:36.467
or whether you are describing a
compiler error, a software replay,

11
00:00:36.641 --> 00:00:41.714
or a physical observation. Clean things
up also invites unrelated changes.

12
00:00:42.155 --> 00:00:45.023
Begin by writing the goal
separately from current behavior.

13
00:00:45.533 --> 00:00:48.982
Our goal is to make the explanatory
report identify its inputs

14
00:00:49.028 --> 00:00:52.685
as synthetic. The current problem is
that a reader can see a temperature

15
00:00:52.731 --> 00:00:56.005
and state without noticing
where the values came from.

16
00:00:56.388 --> 00:01:00.324
That is a communication problem we can
solve without replacing a sensor library

17
00:01:00.440 --> 00:01:04.480
or changing a warning threshold.
Next identify the starting state.

18
00:01:04.806 --> 00:01:09.310
Name the Chapter Three original reporting
resources and the actual input file.

19
00:01:09.751 --> 00:01:12.224
This fixture has explicit validity flags;

20
00:01:12.433 --> 00:01:17.205
the different CP00 inspection log
does not. Keep an unchanged copy.

21
00:01:17.646 --> 00:01:20.793
Later we will identify source
versions using Git commits;

22
00:01:21.002 --> 00:01:24.438
for now, the named resource
gives us a recoverable baseline.

23
00:01:24.821 --> 00:01:27.561
If you already edited it,
provide the current relevant

24
00:01:27.619 --> 00:01:30.916
content rather than assuming
the assistant sees the original.

25
00:01:31.357 --> 00:01:33.935
Supply the context that
could change the solution.

26
00:01:34.446 --> 00:01:37.534
For this task, the sample
records, validity flags,

27
00:01:37.685 --> 00:01:40.169
state names, and origin
requirement matter.

28
00:01:40.866 --> 00:01:44.059
A serial port does not, because
no physical board is involved.

29
00:01:44.384 --> 00:01:48.262
For a different task such as
cross-compilation, the operating system,

30
00:01:48.471 --> 00:01:52.325
shell, compiler, board core,
and target options would matter.

31
00:01:53.277 --> 00:01:55.796
Context should be selected
for the decision rather

32
00:01:55.842 --> 00:01:59.093
than collected indiscriminately.
Paths also need a root.

33
00:02:00.045 --> 00:02:03.749
Open reporting-input dot
JSONL from the Chapter

34
00:02:03.819 --> 00:02:06.141
Three resources linked
in the written lesson.

35
00:02:06.744 --> 00:02:11.620
Inspect its actual contents rather
than substituting CP00's sample log.

36
00:02:12.061 --> 00:02:15.510
Do not refer vaguely to the log
when several files have that name.

37
00:02:15.893 --> 00:02:19.805
A relative path becomes meaningful
only in relation to a known folder,

38
00:02:19.979 --> 00:02:23.973
which the workbench lesson will teach
you to verify. Now write the constraints.

39
00:02:24.356 --> 00:02:28.826
Preserve sample values, validity,
state names, and record order.

40
00:02:29.151 --> 00:02:31.589
Do not change firmware,
timing, dependencies,

41
00:02:31.659 --> 00:02:34.805
or the fixture itself. These
constraints keep the requested

42
00:02:34.851 --> 00:02:37.673
reporting improvement separate
from other possible work.

43
00:02:38.114 --> 00:02:41.933
If the assistant believes an excluded
change is necessary, it should explain

44
00:02:41.991 --> 00:02:46.125
that dependency before editing rather than
surprise you with a much larger patch.

45
00:02:46.635 --> 00:02:48.284
Choose the requested artifact.

46
00:02:48.563 --> 00:02:52.336
We will ask for a short plan and two
illustrative revised report lines.

47
00:02:52.719 --> 00:02:55.587
That is different from asking
an agent to modify files.

48
00:02:55.912 --> 00:02:59.012
The output should be small enough
to inspect immediately. Once

49
00:02:59.035 --> 00:03:01.995
its meaning is correct, a later
task can apply the selected

50
00:03:02.030 --> 00:03:05.002
change with an explicit file
boundary and relevant checks.

51
00:03:05.513 --> 00:03:08.160
Acceptance criteria describe
what you will inspect.

52
00:03:08.601 --> 00:03:12.154
Both example lines must
identify synthetic origin.

53
00:03:12.665 --> 00:03:15.741
Original temperatures and state
labels must remain intact.

54
00:03:16.182 --> 00:03:18.249
Invalid input must remain invalid,

55
00:03:18.400 --> 00:03:22.196
and the answer must not claim a
physical measurement. If no command ran,

56
00:03:22.242 --> 00:03:25.981
the response must not say
tests passed. These criteria

57
00:03:26.027 --> 00:03:30.230
are observable, unlike a broad request to
make the report robust or professional.

58
00:03:30.741 --> 00:03:34.526
Include a negative case. A record can
contain a temperature number and still

59
00:03:34.572 --> 00:03:38.438
be marked invalid. The report must not
promote that number into a trustworthy

60
00:03:38.508 --> 00:03:43.059
reading merely because it is available. If
the input origin is unknown, the assistant

61
00:03:43.082 --> 00:03:46.809
should preserve that unknown rather
than invent a known source. Negative

62
00:03:46.832 --> 00:03:50.024
cases make the boundary of
acceptable behavior easier to see.

63
00:03:50.976 --> 00:03:52.904
Read the completed brief in the editor.

64
00:03:53.078 --> 00:03:57.013
It now names the goal, starting
resource, input, current behavior,

65
00:03:57.188 --> 00:04:01.402
requested artifact, constraints,
sources, and acceptance criteria.

66
00:04:02.006 --> 00:04:05.082
Notice how each part reduces
a specific uncertainty.

67
00:04:05.407 --> 00:04:08.031
We have not made the request
longer for its own sake.

68
00:04:08.275 --> 00:04:11.700
We have made the result easier to
judge and the work easier to resume.

69
00:04:12.025 --> 00:04:15.671
Submit the brief with the actual
relevant input, or analyze the original

70
00:04:15.740 --> 00:04:19.629
reference response if service access
is unavailable. Keep what came back.

71
00:04:19.954 --> 00:04:23.867
If the plan suggests a cloud dashboard,
that idea is outside the task.

72
00:04:24.192 --> 00:04:28.023
If it renames WARN to ALARM, it
violates the state-name constraint.

73
00:04:28.348 --> 00:04:31.878
A suggestion can be interesting and still
be inappropriate for the current change.

74
00:04:32.992 --> 00:04:35.837
Write a short review
against each criterion.

75
00:04:36.162 --> 00:04:38.844
Accept the explicit origin
label if it is correct.

76
00:04:39.227 --> 00:04:42.141
Reject changed values or
state names with a reason.

77
00:04:42.652 --> 00:04:44.893
Identify whether commands actually ran.

78
00:04:45.276 --> 00:04:49.049
A useful review note might say that the
label meets the goal, the state-name

79
00:04:49.095 --> 00:04:53.054
change must be removed, and all
example lines remain illustrative.

80
00:04:53.333 --> 00:04:56.920
This leaves a concrete next
action. For your exercise,

81
00:04:57.094 --> 00:05:01.425
request a summary counting valid and
invalid records in the actual sample log.

82
00:05:01.703 --> 00:05:05.813
Count the records independently first.
Do not copy a count from an illustrative

83
00:05:05.837 --> 00:05:09.679
table elsewhere in the book. Name
the original Chapter Three input,

84
00:05:09.796 --> 00:05:13.905
preserve it, and require the total and
validity split to match your inspection.

85
00:05:14.231 --> 00:05:17.621
Save both the brief and your
evaluation of the returned summary.

86
00:05:18.225 --> 00:05:23.043
A brief can also specify when to ask a
question. Ask for missing information when

87
00:05:23.078 --> 00:05:26.839
its answer would change the implementation
or the meaning of acceptance.

88
00:05:27.281 --> 00:05:30.462
Do not require clarification
for every minor wording choice.

89
00:05:30.845 --> 00:05:35.187
For this report, unknown recovery
behavior may be irrelevant if you only

90
00:05:35.257 --> 00:05:39.971
preserve existing state labels, while
an unknown input format is essential.

91
00:05:40.412 --> 00:05:44.533
This distinction keeps collaboration
efficient: resolve consequential

92
00:05:44.591 --> 00:05:48.782
ambiguity and let routine choices
proceed inside a clear boundary.

93
00:05:49.107 --> 00:05:51.383
If the response expands
into unrelated work,

94
00:05:51.627 --> 00:05:53.682
stop and return to the preserved baseline.

95
00:05:54.007 --> 00:05:57.420
Clarify the permitted output and
restart with the smaller brief.

96
00:05:57.861 --> 00:06:01.727
Repeating be careful is less useful
than naming the exact file and success

97
00:06:01.774 --> 00:06:06.023
condition. You are finished when another
person could identify where to start,

98
00:06:06.197 --> 00:06:08.984
what to produce, and how to
decide whether it is correct

99
00:06:09.030 --> 00:06:11.747
without reconstructing
your entire conversation.