Part 19 · Capstone — a general-purpose personal assistant

Level: ⭐⭐⭐⭐⭐ · Time: ~10 h · Requires: parts 1–18 Produces: a working system, a repeated measurement from part 1, a plan for what comes next

---

0. What you have at this point

                      ┌──────────── CHANNELS ───────────┐        pt. 12
   socket (host) ─────┤  pairing · lists · limits       │
   HTTP (sandbox) ────┤  routing → agent + tools        │
   scheduler (cron) ──┘                                 │        pt. 11
                                  │
                      ┌───────────▼──────────────────────┐
                      │            GATEWAY               │        pt. 2
                      │  one per host · loopback         │
                      │  sessions = event log            │
                      │  trust level per session         │
                      └───────────┬──────────────────────┘
                                  │
                      ┌───────────▼──────────────────────┐
                      │            HARNESS               │        pt. 3
                      │  task registry · progress · git  │
                      │  5 stop conditions · error ladder│
                      └───────────┬──────────────────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        ▼                         ▼                         ▼
  ┌───────────┐            ┌───────────┐            ┌───────────┐
  │ ARCHIVIST │            │RESEARCHER │            │   HOST    │   pt. 6
  │ documents │            │  network  │            │ calendar  │
  │ bwrap     │            │ ⭐ strict │            │  light    │   pt. 10
  │ no network│            │ proxy 4×  │            │ proactive │   pt. 11
  └─────┬─────┘            └─────┬─────┘            └─────┬─────┘
        └────────────────────────┼────────────────────────┘
                                 ▼
   context pt.4 · bi-temporal memory pt.5 · tools pt.7 · code-mode pt.8
   protocols pt.9 · fleet pt.13 · evaluation pt.14 · traces pt.15
   ASI01-10 pt.16 · router pt.17 · releases pt.18

This is not a demo. It is a system with a log from which you can reconstruct every decision; with a memory that knows when something stopped being true; with a sandbox you tried to break sixteen times; with a gate that will not let a degradation through; and with a runbook written before it was needed.

---

1. The acceptance task

One command that touches everything you have built:

"Go through my documents from the last quarter. Find everything that has a deadline in the next 60 days. For things where the regulations may have changed — check it. Set reminders with appropriate lead time. Write me a one-page summary and tell me what you were not sure about."

Why this one. The task requires:

---

2. Acceptance criteria

2.1 · Functional

• Finishes the task in ≤3 sessions, with no intervention from you beyond approvals
• The summary quotes the file and the passage for every claim
• The "what I was not sure about" section is non-empty and on point
• Reminders in the calendar, each with lead time appropriate to the matter
• When one stage fails, returns a partial result with an explicit annotation

2.2 · Architectural — verified from traces, not from declarations

• The Researcher did not touch ~/dokumenty — confirmed by traces (pt. 15)
• Nothing from ~/dokumenty left the machine — egress audit (pt. 17)
• Every write operation had consent with a summary built from code (pt. 16)
• The Researcher's result reached the rest wrapped as data (pt. 13)
• Full trace: agent → workflow → model → tool (pt. 15)

2.3 · Operational

• kontrola.py — 12/12
• Golden set ≥50 questions, score above the baseline
• ASI attacks ≥18/20
• 16 escape attempts — all blocked
• Full offline — zero failed tasks
• Rollback to the previous release in under 5 minutes

---

3. EXPERIMENT 19 — measuring the whole course

⭐ Go back to pomiary/01-gdzie-peka.md from part 1. The same five tasks Z1–Z5, the same model, the same hardware. Only the system around the model has changed.

python3 ewaluacja/uruchom.py --zestaw pomiary/01-gdzie-peka.md \
  --przebiegow 3 --porownaj-z pomiary/01-wyniki-bazowe.csv

Failure-mode breakdown — did the ones that were supposed to disappear actually go:

⭐ This is the only assessment of this course that means anything. Not the number of pages read — the number of tasks that now finish and previously did not.

⚠️ If any failure mode did not disappear — go back to the indicated part. That is not a failure, just a diagnosis. The course is built so that every mode has a remedy assigned.

---

4. How you know it is really yours

Six questions. If you cannot answer any of them without looking — go back to that part.

⭐ Question 6 is the crux. If you know your number, it means you measure instead of believing — and that is the one habit from this course that really has to stay.

---

5. What next

5.1 · The next few weeks

5.2 · Directions for growth — in order of return

⚠️ The last two rows are traps with a strong pull. Fine-tuning a model and inter-agent protocols are the most pleasant known ways to waste a quarter — because they sound like sophistication, and your bottleneck lies elsewhere. Postpone them until a measurement says otherwise.

5.3 · Keeping it alive

Three things you do always. The rest is optional.

1. ⭐ The regression gate before every change. Without it the system degrades imperceptibly through good intentions.
2. ⭐ The nightly job. Evaluation, memory audit, drift detection, backup. Free.
3. ⭐ Three new questions a month from real failures.

💡 One closing observation about how this system ages. The code will work for years. The numbers will age — context thresholds, router levels, the limit of concurrent sessions. All of them come from measurements on two cards, on specific models, in September 2026. After every hardware or model change repeat experiments 4, 7, 8, 13 and 17 — it is half a day's work and the only way to keep the system from living in the past.

---

6. Trap registry — P60–P139

Eighty traps from the whole course. Go through them once when you finish — half will sound obvious, and the other half like something you just stepped in.

---

7. Final checkpoint

cd $OSA

python3 wydanie/kontrola.py                                    # 12/12
python3 ewaluacja/uruchom.py --przebiegow 3                    # > baseline
python3 testy/ataki/ataki.py --wszystkie                       # ≥18/20
python3 testy/ucieczka/proby.py --poziom scisly --wymagaj-porazki-wszystkich
python3 ewaluacja/uruchom.py --offline --wymagaj-zero-nieudanych
python3 router/audyt.py --okres 30d                            # Archivist: 0
python3 ewaluacja/uruchom.py --zestaw pomiary/01-gdzie-peka.md \
        --porownaj-z pomiary/01-wyniki-bazowe.csv              # ⭐ course assessment

bash wydanie/wydaj.sh 1.0.0
git tag -l && git log --oneline | wc -l

• The acceptance task passes in ≤3 sessions
• All the criteria from §2.1, §2.2 and §2.3
• ⭐ Z1–Z5 measured again; the failure modes have gone
• You can answer the six questions from §4
• Release 1.0.0 with a manifest and an evaluation result

---

8. In closing

You have built something that cannot be bought: a system that you understand in its entirety. Every threshold comes from your own measurement, every boundary is in code you wrote, and every decision has an ADR with a falsification condition.

The biggest lesson is not technical. It came back in every part, and it goes like this:

⭐ The variable you have full control over — the system around the model — is more important than the variable you have no control over at all.

That is why you measured the harness, not the weights. That is why you wrote boundaries in code, not in the prompt. That is why the golden set has a "correct refusal" category, and the approval summary is built by code, not by the model.

The model you use today will be obsolete in a year. Everything else you built will remain — and will take on the next model without changing a single line.

Now use it. The things it breaks in the first month will be a better teacher than this course.