WEBVTT

1
00:00:00.000 --> 00:00:03.611
The workflow becomes yours when you
can apply it to a small task outside

2
00:00:03.646 --> 00:00:07.767
the exact course sequence. In this
lesson, you will complete one bounded

3
00:00:07.802 --> 00:00:11.482
transfer and evaluate the whole effort
needed to reach a verified result.

4
00:00:11.865 --> 00:00:15.046
Use an appropriate local project
or the supplied checkpoint-nine

5
00:00:15.081 --> 00:00:18.855
README clarification. You do not
need a new framework, subscription,

6
00:00:18.890 --> 00:00:23.081
or board to finish this work. Choose
a task whose outcome you can observe.

7
00:00:23.464 --> 00:00:26.425
Examples include adding a
missing error-path assertion,

8
00:00:26.703 --> 00:00:30.523
improving a reproducible setup step,
or clarifying a report format.

9
00:00:30.906 --> 00:00:34.203
Avoid a broad goal such as
modernize the entire project.

10
00:00:34.586 --> 00:00:38.325
A small task makes it easier to
connect requirements, source changes,

11
00:00:38.499 --> 00:00:41.530
verification, and the effort
you spend reviewing the result.

12
00:00:41.971 --> 00:00:45.419
The supplied example asks you to
clarify two different outcomes.

13
00:00:45.744 --> 00:00:50.307
A malformed fixture is rejected with
a line-number diagnostic and exit two.

14
00:00:50.690 --> 00:00:54.138
A valid replay can intentionally
produce fault and still exit

15
00:00:54.207 --> 00:00:57.435
zero. The README should explain
that distinction without

16
00:00:57.481 --> 00:01:01.069
changing parser behavior or implying
that a physical sensor failed.

17
00:01:01.394 --> 00:01:04.784
This is a complete maintenance task
with a clear acceptance condition.

18
00:01:05.167 --> 00:01:06.700
Write a brief before editing.

19
00:01:07.083 --> 00:01:12.528
Name the goal, starting source, relevant
context, scope, and observable result.

20
00:01:13.039 --> 00:01:17.369
Preserve a baseline so you can compare
changes and recover without erasing useful

21
00:01:17.427 --> 00:01:21.247
work. The brief should be understandable
without the old conversation.

22
00:01:21.630 --> 00:01:25.519
If you use an agent, it supplies
the current task while repository

23
00:01:25.577 --> 00:01:29.594
guidance and references supply
maintained project context.

24
00:01:29.919 --> 00:01:33.716
Read the format documentation and
fixtures for the example task.

25
00:01:34.099 --> 00:01:38.034
Do not infer behavior from a vague
memory of what a fault usually means.

26
00:01:38.417 --> 00:01:41.784
The project distinguishes
input-file validity, policy state,

27
00:01:41.808 --> 00:01:45.244
and process result. Those definitions
tell you what the paragraph

28
00:01:45.302 --> 00:01:48.518
needs to say and which commands
can establish the distinction.

29
00:01:49.029 --> 00:01:51.920
Make the bounded wording
change and inspect the diff.

30
00:01:52.245 --> 00:01:55.008
The task does not require
modifying the intentionally

31
00:01:55.066 --> 00:01:58.189
malformed fixture so
every command succeeds.

32
00:01:58.700 --> 00:02:02.798
Removing the fault would weaken the
demonstration. Preserve the relevant input

33
00:02:02.914 --> 00:02:06.502
and use its actual diagnostic
as evidence for the explanation.

34
00:02:06.827 --> 00:02:11.239
A documentation repair should not silently
change the software behavior it describes.

35
00:02:11.564 --> 00:02:14.257
Run the relevant replay
examples from the project root.

36
00:02:14.582 --> 00:02:18.797
Record actual commands, source
identity, output, and process results.

37
00:02:19.122 --> 00:02:22.907
If an environment issue prevents
execution, state the limitation.

38
00:02:23.510 --> 00:02:26.192
A supplied expected
result is useful guidance,

39
00:02:26.517 --> 00:02:28.503
but it is not a receipt from your run.

40
00:02:29.013 --> 00:02:32.752
Keep the evidence's synthetic origin
visible throughout the explanation.

41
00:02:33.193 --> 00:02:38.720
Now examine effort. Generation or typing
time is only part of verified delivery.

42
00:02:39.045 --> 00:02:42.481
Include preparation, editing
or generation, review,

43
00:02:42.597 --> 00:02:46.220
diagnosis and repair,
verification, and waiting.

44
00:02:46.603 --> 00:02:49.111
A response that arrives
quickly can still require

45
00:02:49.157 --> 00:02:52.059
substantial work before it is
correct and understandable.

46
00:02:52.501 --> 00:02:55.601
A slower first pass may
reduce later repair.

47
00:02:56.112 --> 00:02:59.270
Measure the end point that
actually matters to your project.

48
00:02:59.711 --> 00:03:01.777
Separate active effort from waiting.

49
00:03:02.219 --> 00:03:06.863
Active effort is time you spend preparing,
reading, editing, reviewing, or checking.

50
00:03:07.304 --> 00:03:12.040
Waiting may include model response,
compilation, downloads, or account limits.

51
00:03:12.482 --> 00:03:16.499
These categories can move in different
directions. Recording both gives a more

52
00:03:16.557 --> 00:03:20.446
useful picture than one unexplained
number called time saved.

53
00:03:20.771 --> 00:03:23.662
If you compare manual and
AI-assisted approaches,

54
00:03:23.940 --> 00:03:27.621
use separate identical starting
copies and common acceptance criteria.

55
00:03:28.132 --> 00:03:29.989
Do not give one a complete source pack

56
00:03:30.105 --> 00:03:33.971
and the other an ambiguous prompt without
recording that difference. Preserve

57
00:03:34.006 --> 00:03:36.328
both artifacts and their review outcomes.

58
00:03:36.769 --> 00:03:39.393
A single task can reveal
useful information,

59
00:03:39.637 --> 00:03:43.271
but it does not establish a
permanent ranking of tools or models.

60
00:03:44.385 --> 00:03:46.440
Leave unmeasured fields unmeasured.

61
00:03:46.765 --> 00:03:50.596
Do not fill a timing table with plausible
numbers because it looks unfinished.

62
00:03:50.980 --> 00:03:55.182
You can report a qualitative observation
and design a better measurement next time.

63
00:03:55.693 --> 00:03:59.733
The same rule applies to learner
feedback: your own review or an agent

64
00:03:59.780 --> 00:04:03.553
walkthrough is not evidence that
another person tested the instructions.

65
00:04:03.936 --> 00:04:07.942
Build a small maintenance table for
the result. Name the source or tool,

66
00:04:08.058 --> 00:04:12.110
its current recorded version, the trigger
for review, and the relevant check.

67
00:04:12.389 --> 00:04:15.419
A compiler update calls for
build and behavior evidence.

68
00:04:15.860 --> 00:04:19.842
A skill-description change calls for
relevant and unrelated selection cases.

69
00:04:20.283 --> 00:04:24.010
A repaired link calls for navigation
and rendered-content review.

70
00:04:24.393 --> 00:04:28.863
The check should match what changed.
Keep a working baseline before updates.

71
00:04:29.246 --> 00:04:32.845
Use a separate branch or disposable
copy, read current official

72
00:04:32.915 --> 00:04:36.967
guidance for the component being changed,
and preserve the earlier result.

73
00:04:37.350 --> 00:04:40.763
If the update fails, record the
demonstrated incompatibility

74
00:04:40.833 --> 00:04:43.921
and return to the known state
in that exercise environment.

75
00:04:44.432 --> 00:04:48.275
Rollback should not erase the evidence
explaining why the update was rejected.

76
00:04:48.716 --> 00:04:51.050
Record conditions that
can affect a comparison.

77
00:04:51.433 --> 00:04:55.601
A first build may spend time creating
output that a later run can reuse.

78
00:04:56.042 --> 00:04:59.653
One task may begin with a source
already open while another includes

79
00:04:59.676 --> 00:05:02.996
searching for it. These are not
reasons to abandon measurement;

80
00:05:03.275 --> 00:05:07.814
they are reasons to describe the starting
conditions. When possible, alternate

81
00:05:07.837 --> 00:05:12.237
approach order across repeated tasks
and keep the completion criteria fixed.

82
00:05:12.748 --> 00:05:17.090
For a different board, transfer the
workflow before copying hardware facts.

83
00:05:17.532 --> 00:05:20.364
Re-establish the exact product, sources,

84
00:05:20.445 --> 00:05:23.441
target options, and any
physical interface assumptions.

85
00:05:24.137 --> 00:05:28.607
Hardware-independent policy may remain
useful if its requirements still apply.

86
00:05:28.990 --> 00:05:31.742
Pin mappings and power
aliases should not travel

87
00:05:31.823 --> 00:05:34.563
merely because the processor
family is familiar.

88
00:05:35.004 --> 00:05:38.917
Compilation on the new target still has
a separate physical-evidence boundary.

89
00:05:39.358 --> 00:05:43.097
Your exercise submission contains
the brief, artifact, diff,

90
00:05:43.189 --> 00:05:46.719
actual results, effort record,
and a three-item maintenance plan.

91
00:05:47.044 --> 00:05:50.944
Finish with a concise handoff naming
the completed task and its evidence,

92
00:05:51.153 --> 00:05:52.802
or the exact remaining question.

93
00:05:53.754 --> 00:05:57.376
A successful transfer is one
you can explain and verify.

94
00:05:57.701 --> 00:06:01.115
It does not become more advanced
simply because it involves more tools.

95
00:06:01.556 --> 00:06:02.879
Pause here to complete

96
00:06:02.914 --> 00:06:06.885
the task. When reviewing it, ask
whether another session could understand

97
00:06:06.919 --> 00:06:10.228
the result without your conversation
and repeat the relevant check.

98
00:06:10.739 --> 00:06:15.081
Then explain one thing you learned about
total effort, including review and repair.

99
00:06:15.522 --> 00:06:19.028
This makes the workflow adaptable:
it helps you choose where an assistant

100
00:06:19.063 --> 00:06:20.921
is useful while retaining responsibility

101
00:06:20.979 --> 00:06:24.520
for the evidence and the decisions
that turn output into engineering work.