Checkpoint Lab — Capstone: Build a Governed End-to-End Robot Framework Automation Platform

1. Checkpoint scenario and acceptance contract

You are the maintainer receiving a Robot Framework estate for production adoption. The code is useful, but adoption is blocked until the team can prove safe target selection, reproducible dependencies, secret-safe integration, deterministic serial behavior, one alternate execution mode, retained evidence on failure, style/static quality, performance budgets, and a repeatable incident process.

2. Preflight and predictions

Before execution, write two predictions in evidence/predictions.txt. Example: (1) setting RF_CAPSTONE_TOKEN will create a Secret object in Robot data, while the raw value should not appear in normal Robot logs; (2) switching the container base URL from loopback to fixture will change only the external target resolution layer, not suite/test names or expected statuses.

python --version
python -m robot --version
python -m pip freeze
robocop --version
pabot --version
python -m robot --dryrun --outputdir results/checkpoint-dryrun tests

Record all command output or version files. The checkpoint fails if the environment is reconstructed from memory after an incident.

3. Establish the clean serial baseline

Start the local fixture with the fake token in Terminal A. In Terminal B, set the same fake token and run the quality + execution + post-processing gates. Time the serial Robot command using a shell-appropriate timing mechanism and record the wall-clock value, suite/test counts, and output size.

robocop check tests resources
robocop format --check tests resources
python -m robot --outputdir results/final-serial --log NONE --report NONE tests
python -m robot.rebot --outputdir results/final-published --name "Governed Capstone Final" results/final-serial/output.xml

Do not delete a failing output.xml before the investigation. If the clean run fails unexpectedly, that real failure becomes the first incident and must be explained before seeded failures continue.

4. Exercise one alternate execution mode

Option A — Pabot

pabot --processes 2 --outputdir results/final-pabot tests/parallel

Compare suite/test counts, pass/fail semantics, and mutable-resource ownership to serial execution. Preserve worker/manager evidence.

Option B — private container path

docker compose -f containers/compose.yaml up --build --abort-on-container-exit --exit-code-from robot

Confirm the Robot service uses http://fixture:8765, the result volume persists outside the ephemeral container, and no fixture port is published publicly. The mandatory course outcome is architecture understanding; if Docker is unavailable, Pabot provides the free local alternate path.

5. Inject four failures and recover

For every incident create evidence/incidents/Ix.md with: exact command; versions; expected versus observed state; first bad layer; preserved artifact paths; root-cause statement; repair; smallest rerun; regression-prevention control; and cleanup. Do not write “flaky” as the root cause.

6. Optional advanced incidents

If the four required incidents finish cleanly, add one of these: make the CI wrapper ignore Robot’s exit code; change the custom library scope to GLOBAL and introduce mutable per-test state; skip artifact retention on failure; add a Robocop bypass; or inject a measurable 30% wait regression. The repair must preserve correctness and evidence, not merely restore green status.

7. Audit retained artifacts for the fake marker

Search only the disposable capstone tree. The expected source locations containing the literal fake marker are documentation/lab configuration where deliberately declared; generated Robot evidence from a clean run should not reveal the runtime Secret value. Classify findings instead of deleting them blindly.

# Bash example: scoped to disposable results/evidence only
grep -R --line-number --fixed-strings 'capstone-FAKE_DO_NOT_USE' results evidence || true

# PowerShell equivalent
# Get-ChildItem results,evidence -Recurse -File | Select-String -SimpleMatch 'capstone-FAKE_DO_NOT_USE'

If a generated artifact contains the marker, identify which keyword/library/source boundary emitted it, preserve a restricted incident copy, repair the source, and rerun. Do not claim Robot Secret values are encrypted.

8. Set runtime and output budgets from the measured baseline

Budgets should be relative to a known clean baseline and stable hardware class, not universal numbers copied from this course. Example policy:

9. Production-readiness review

10. Deliver the operating/governance runbook

RUNBOOK — Governed Robot Framework Platform

Owners
- Platform owner: dependency/runtime/evidence/CI contracts
- Domain owner: suite intent and system-under-automation contracts
- Security owner: target/secret/evidence policy

Normal operation
1. Activate the approved environment and record versions.
2. Resolve approved target + Secret injection.
3. Run dry-run and Robocop gates.
4. Run serial Robot command; preserve raw output.xml.
5. Post-process with Rebot.
6. Run alternate mode only when required by the gate.
7. Upload/retain evidence even if Robot failed.

Incident response
1. Freeze first-failure artifacts and exact command/environment.
2. Identify first bad layer using the Chapter 29/30 diagnostic sequence.
3. Apply least destructive repair.
4. Rerun smallest affected slice.
5. Run full regression + secret/style/performance checks.
6. Add a prevention control and update the runbook.

Upgrade policy
- Evaluate candidate Python/Robot/external libraries/tools in a compatibility lane.
- Change one dependency family at a time where practical.
- Compare status counts, warnings/deprecations, output schema/size, runtime, Pabot/container behavior.
- Roll back unexplained semantic/evidence changes.
- Update pins + matrix + runbook together.

11. Cleanup and rollback

Stop the local fixture with Ctrl+C. Remove only the disposable capstone virtual environment/results if desired; retain the evidence packet required for grading/review. For containers, stop/remove the lab stack and verify no host port or persistent secret remains. Never generalize these cleanup commands to unrelated directories or running processes.

docker compose -f containers/compose.yaml down --remove-orphans
# Review paths before deleting anything:
python -c "from pathlib import Path; print(Path('results').resolve()); print(Path('evidence').resolve())"

12. What this chapter adds to the production operating model

The completed course now ends with an automation platform that can explain itself: what it is allowed to target, where state lives, how secrets cross boundaries, how source becomes results, which execution modes are supported, which artifacts prove the outcome, how quality/performance are governed, and how a maintainer responds when any layer fails. That operating model—not the demo fixture—is the transferable capstone.

Knowledge check

Further reading

• Robot Framework User Guide 7.4.2 — authoritative core behavior for this dated capstone.
• Robot Framework releases — upgrade lane input.
• RequestsLibrary, Pabot, and Robocop.
• Browser Library and SeleniumLibrary — optional UI architecture path.
• Robot Framework course curriculum — use the earlier chapters as the detailed reference for each layer summarized in this capstone.

This final lesson intentionally keeps cloud/CI-provider administration, browser-stack administration, Docker/Kubernetes operation, and secret-manager administration at their Robot integration boundaries. Use the dedicated DevOps Academy courses for those platforms.