WEBVTT

00:00:00.600 --> 00:00:02.264
One broken tab order.

00:00:03.264 --> 00:00:05.696
One student who can't
book the help they need.

00:00:06.696 --> 00:00:09.107
The site is up. The form is not usable.

00:00:12.900 --> 00:00:14.905
STILL keeps a second route open.

00:00:15.905 --> 00:00:18.423
The student switches to
the simple form, uses

00:00:18.423 --> 00:00:21.388
only the keyboard, and books
a synthetic appointment.

00:00:22.388 --> 00:00:25.567
The receipt is read back from
the database with a private key.

00:00:28.567 --> 00:00:31.682
A basic uptime check still
says healthy, two hundred.

00:00:32.682 --> 00:00:36.778
A browser probe that actually presses
Tab sees that nobody can choose a time.

00:00:37.778 --> 00:00:40.714
While CI minutes lasted,
a scheduled GitLab job

00:00:40.714 --> 00:00:43.900
ran both, and reported the
broken route as failing.

00:00:48.100 --> 00:00:50.831
The failure is tracked
in a public GitLab issue.

00:00:52.331 --> 00:00:55.735
A GitLab Duo Developer flow
read it, searched the code,

00:00:55.735 --> 00:00:59.200
edited one line and committed
it, in ten recorded steps.

00:01:00.700 --> 00:01:04.040
That session ran in a private
Duo project, so its raw

00:01:04.040 --> 00:01:07.569
trace is committed to this
repository. Duo ran no tests.

00:01:09.069 --> 00:01:13.699
The public merge request one is the owner's
matching change, not the Duo session.

00:01:17.900 --> 00:01:21.523
The last green pipeline on
that merge request ran on 24

00:01:21.523 --> 00:01:26.199
October: Rust tests, web tests,
security checks and package validation.

00:01:27.699 --> 00:01:32.176
Then, on 25 October, the project
ran out of CI minutes. New jobs fail

00:01:32.176 --> 00:01:37.043
with no more compute minutes available,
and the schedule shows as inactive.

00:01:38.543 --> 00:01:41.044
What still holds: ask
for a receipt without the

00:01:41.044 --> 00:01:43.599
private key, and the
server answers four oh one.

00:01:48.800 --> 00:01:50.763
The causeway shows both halves.

00:01:52.363 --> 00:01:54.786
Above, the person finishes now. Below, the

00:01:54.786 --> 00:01:57.440
team goes from bug caught
to review and tests.

00:01:59.040 --> 00:02:01.926
This part is a guided
simulation of the documented

00:02:01.926 --> 00:02:04.928
incident, and every station
links to the real thing.

00:02:06.528 --> 00:02:09.853
The operator console shows the
failed scheduled run and the

00:02:09.853 --> 00:02:13.291
open merge request, and the
release still waits for a person.

00:02:19.500 --> 00:02:20.332
STILL.

00:02:21.332 --> 00:02:22.889
The person finishes now.

00:02:23.889 --> 00:02:25.639
The next release gets safer.
