WEBVTT

1
00:00:00.000 --> 00:00:02.845
A useful review procedure
finds supported correctness

2
00:00:02.891 --> 00:00:06.130
issues and leaves clean
work alone. In this lesson,

3
00:00:06.188 --> 00:00:09.903
we will evaluate the firmware-review
skill and write a concise handoff.

4
00:00:10.507 --> 00:00:13.618
Start with checkpoint eight.
It contains the second skill,

5
00:00:13.735 --> 00:00:17.670
normal and fault policy, synthetic
replay, and basic assertions.

6
00:00:17.949 --> 00:00:21.699
The capstone's thresholds and commands
are still future work at this stage.

7
00:00:22.141 --> 00:00:27.121
Open the firmware-review skill under
dot agents, skills, and firmware-review.

8
00:00:27.562 --> 00:00:29.524
Read the description before the body.

9
00:00:29.733 --> 00:00:33.797
The task is a bounded review of
embedded firmware or shared C++

10
00:00:33.867 --> 00:00:37.442
policy for actionable correctness
issues. It is not a request

11
00:00:37.477 --> 00:00:41.529
to rewrite the entire repository or
perform an unrelated security audit.

12
00:00:41.773 --> 00:00:45.813
A clear boundary makes both selection
and output easier to evaluate.

13
00:00:46.324 --> 00:00:50.213
The procedure begins with the
exact diff, nearby callers,

14
00:00:50.329 --> 00:00:53.035
applicable requirements,
and relevant evidence.

15
00:00:53.313 --> 00:00:56.889
It examines timing,
invalid input, stale data,

16
00:00:57.098 --> 00:01:00.778
recovery, bounds,
conversions, and useful tests.

17
00:01:01.289 --> 00:01:02.961
These are inspection lenses.

18
00:01:03.170 --> 00:01:06.978
The reviewer does not need to invent
one finding in every category.

19
00:01:07.419 --> 00:01:11.401
A clean diff can legitimately produce
no supported correctness issue.

20
00:01:11.912 --> 00:01:15.987
A finding should name a file and
location, a concrete trigger,

21
00:01:16.162 --> 00:01:19.610
the resulting consequence, and a
check or source that supports it.

22
00:01:20.051 --> 00:01:23.290
A vague warning about timing
is difficult to act on.

23
00:01:23.615 --> 00:01:26.901
A statement that a last sample
remains current after its age

24
00:01:27.145 --> 00:01:30.686
exceeds the freshness limit
identifies a behavior the engineer

25
00:01:30.755 --> 00:01:34.389
can reproduce. The report should
also distinguish executed evidence

26
00:01:34.412 --> 00:01:37.977
from a prediction. We will
use the supplied stale-policy

27
00:01:38.046 --> 00:01:41.727
defect. Keep checkpoint eight active
in a checkout cloned from the history

28
00:01:41.785 --> 00:01:44.095
bundle so the review
skill remains available.

29
00:01:44.420 --> 00:01:47.009
Inspect the bounded difference
from checkpoint seven

30
00:01:47.102 --> 00:01:50.411
to the fault-stale tag using the
command in the written lesson.

31
00:01:50.922 --> 00:01:55.102
That diff changes the polling expiration
path. We are reviewing it without

32
00:01:55.171 --> 00:01:58.829
switching away from the checkpoint
containing the skill. This setup

33
00:01:58.887 --> 00:02:02.672
detail matters. The fault-stale
snapshot is based on checkpoint

34
00:02:02.741 --> 00:02:05.818
seven and does not itself
contain the second skill.

35
00:02:06.143 --> 00:02:09.336
A skill file cannot be discovered
in a folder where it is absent.

36
00:02:09.661 --> 00:02:11.251
Keeping checkpoint eight active

37
00:02:11.275 --> 00:02:14.734
while supplying the exact fault
diff makes the review reproducible.

38
00:02:15.118 --> 00:02:18.612
Execute the faulty source later
in a separate exercise copy

39
00:02:18.937 --> 00:02:23.070
so the review workspace remains preserved.
Ask for review without repair.

40
00:02:23.395 --> 00:02:27.169
The requirement says that a sample
from timestamp one thousand is still

41
00:02:27.250 --> 00:02:30.965
current at four thousand but
stale at four thousand and one.

42
00:02:31.407 --> 00:02:33.856
The mutation disables expiration,

43
00:02:34.181 --> 00:02:37.409
leaving the cached reading current
when it should be unavailable.

44
00:02:37.792 --> 00:02:41.786
The expected finding connects that
trigger to the polling path and output

45
00:02:41.844 --> 00:02:45.327
consequence. It does not merely
complain about formatting.

46
00:02:45.768 --> 00:02:48.636
Inspect the actual response independently.

47
00:02:49.077 --> 00:02:52.827
Follow its file reference and compare
the claim with the requirement. If

48
00:02:52.874 --> 00:02:56.171
the tool ran a reproducer,
preserve the command and result.

49
00:02:56.554 --> 00:03:01.186
If it reasoned from source alone, label
the consequence predicted until tested.

50
00:03:01.697 --> 00:03:06.144
The expected finding described in this
lesson is an acceptance criterion,

51
00:03:06.353 --> 00:03:09.557
not a substitute for the response
your run actually produced.

52
00:03:10.161 --> 00:03:13.167
Now evaluate a clean case
in a disposable copy.

53
00:03:13.608 --> 00:03:16.325
Consistently rename a
local variable without

54
00:03:16.383 --> 00:03:19.251
changing behavior and
ask for a bounded review.

55
00:03:19.855 --> 00:03:22.757
First confirm that your
rename is actually consistent.

56
00:03:23.198 --> 00:03:25.973
The desired reviewer behavior
is an accurate assessment,

57
00:03:26.147 --> 00:03:29.537
not a compulsory defect. A
report that invents a correctness

58
00:03:29.583 --> 00:03:33.229
problem to fill its format is a
finding about the review procedure.

59
00:03:33.740 --> 00:03:37.095
For the unrelated case,
start a fresh task and ask

60
00:03:37.153 --> 00:03:40.601
for a small README sentence
improvement without changing firmware.

61
00:03:41.042 --> 00:03:44.131
Do not name the review skill.
This checks whether ordinary

62
00:03:44.189 --> 00:03:47.567
documentation stays outside
the firmware-review procedure.

63
00:03:47.892 --> 00:03:51.282
Explicitly selecting the skill
would change the test and make

64
00:03:51.352 --> 00:03:54.289
unwanted implicit activation
harder to evaluate.

65
00:03:54.672 --> 00:03:57.261
Record selection and
output quality separately.

66
00:03:57.505 --> 00:04:01.673
When the interface exposes a skill
read or activation, keep that evidence.

67
00:04:01.847 --> 00:04:05.922
If it does not, avoid inferring selection
solely from the shape of the answer.

68
00:04:06.364 --> 00:04:09.684
You can still evaluate whether the
output was useful and supported.

69
00:04:10.288 --> 00:04:14.862
Unknown selection should remain unknown
rather than becoming an invented pass.

70
00:04:15.303 --> 00:04:18.229
After these cases, write a short handoff.

71
00:04:18.612 --> 00:04:22.385
Name the active source,
completed work, actual receipts,

72
00:04:22.466 --> 00:04:25.601
open questions, and one
bounded next action.

73
00:04:25.926 --> 00:04:29.676
The supplied checkpoint-eight
handoff asks for a negative-infinity

74
00:04:29.734 --> 00:04:32.741
assertion that leaves
production behavior unchanged.

75
00:04:33.183 --> 00:04:36.294
It is a useful restart task
because the requirement

76
00:04:36.352 --> 00:04:39.777
already exists and the expected
change can remain small.

77
00:04:40.474 --> 00:04:44.026
If you already added that assertion
while extending the testing chapter,

78
00:04:44.270 --> 00:04:47.834
use a fresh checkpoint-eight
copy for the restart exercise.

79
00:04:48.345 --> 00:04:52.025
Duplicating the same test would
not demonstrate new behavior.

80
00:04:52.467 --> 00:04:56.147
A preserved starting state also makes
it easier to compare what the fresh

81
00:04:56.205 --> 00:05:00.559
session discovers and changes without
relying on the old conversation.

82
00:05:00.884 --> 00:05:04.053
The review procedure also
preserves action boundaries.

83
00:05:04.495 --> 00:05:09.034
Reading a diff and identifying a defect
does not automatically request a repair,

84
00:05:09.150 --> 00:05:12.935
upload, or remote publication.
If the task is review-only,

85
00:05:13.109 --> 00:05:16.151
report the supported finding
and its verification status.

86
00:05:16.534 --> 00:05:20.772
Runtime permissions still govern
available operations; a sentence

87
00:05:20.818 --> 00:05:24.882
inside the skill cannot grant capabilities
that the environment does not provide.

88
00:05:25.323 --> 00:05:28.748
Your submission contains the
skill version, defect review,

89
00:05:28.957 --> 00:05:31.999
clean review, unrelated task, and handoff.

90
00:05:32.440 --> 00:05:34.750
Preserve actual prompts and results.

91
00:05:35.133 --> 00:05:39.266
A static format check can confirm
that the skill package is well formed,

92
00:05:39.440 --> 00:05:43.214
but it cannot establish runtime
selection or a supported review finding.

93
00:05:43.655 --> 00:05:46.999
Keep those evidence categories
distinct in the final note.

94
00:05:47.324 --> 00:05:49.936
Pause here to complete
the cases and handoff.

95
00:05:50.215 --> 00:05:53.303
If a weakness appears, make
one repair that addresses

96
00:05:53.350 --> 00:05:56.322
the observed cause and
repeat the affected cases.

97
00:05:56.647 --> 00:06:00.037
A narrower description should
still select relevant reviews.

98
00:06:00.421 --> 00:06:04.681
Stronger evidence wording should reduce
unsupported findings without hiding

99
00:06:04.763 --> 00:06:09.140
genuine defects. Keep the failed attempt
so the improvement can be assessed.

100
00:06:09.465 --> 00:06:13.574
You now have a second reusable procedure
with a practical evaluation set.

101
00:06:13.899 --> 00:06:18.276
Its value comes from helping you inspect
a bounded change and preserve evidence,

102
00:06:18.659 --> 00:06:20.563
not from producing many findings.

103
00:06:20.947 --> 00:06:24.789
In the next lesson, a fresh session
will use the repository handoff

104
00:06:24.998 --> 00:06:28.620
to complete one small test change
and show whether this context

105
00:06:28.667 --> 00:06:31.906
can carry useful work across
a conversation boundary.