Main Workstation Interference

1. A slow workstation does not prove the cause

When an editor, terminal, or browser becomes sluggish, do not jump directly to hardware or OS failure. This lesson owns the case where a background build, container, indexing task, or model job measurably harms an interactive foreground workflow through CPU, memory, or I/O contention. Diagnose from per-workload evidence and responsiveness, not from a vague report of slowness.

2. Measure foreground and background separately

The foreground is the workflow whose responsiveness matters to the user; the background is the workload that can consume resources without being directly interactive. For each time window, record foreground latency next to background CPU, memory, and pressure evidence. Host-wide utilization alone is weak attribution evidence.

3. A container boundary is not resource isolation

Docker containers have no hard resource constraints by default and can consume host CPU or memory as allowed by the kernel scheduler. “It is in a container” is therefore not proof of isolation. Configure an explicit CPU or memory boundary and observe its effect before claiming containment.

4. Do not equate CPU saturation with interference

High CPU can be healthy. If foreground latency stays within its SLO and background progress remains acceptable, 95% CPU alone is not a failure. CPU_INTERFERENCE needs a responsiveness violation plus CPU pressure or contention evidence that fits the observed behavior.

5. Memory pressure semantics matter more than raw usage

In cgroup v2, memory.high is a reclaim/throttling boundary and memory.max is a harder final limit. High memory use without pressure is not automatically a failure. High latency combined with reclaim pressure or a memory-limit event can support MEMORY_INTERFERENCE; keep that evidence distinct from CPU evidence.

6. I/O bursts can change the diagnosis

A workload can use modest CPU yet stall an interactive workflow through writes, indexing, swap, or reclaim I/O. If the transfer fixture lowers CPU while I/O pressure rises, simply reusing the old CPU quota is overfitting. Rebuild the dominant-pressure decision from the new evidence.

7. A limit event is not the whole root cause

Throttling, a memory-high event, or even an OOM event is important observation, but it is not complete causal proof by itself. Compare foreground latency, pressure, and background progress before and after the event. A limit can contain a workload while still representing a poor policy.

8. Workstation Resource Isolation & Responsiveness Record v1

The owned artifact tracks foreground latency, background CPU, background memory, CPU/memory/I/O pressure, limit configuration, throttle/OOM events, background progress, host responsiveness, a negative control, and closure replay. Every decisive field is observation, authority, inference, or explicit UNKNOWN.

9. Isolation policy must be bounded

A good policy does more than keep the workstation responsive; it must preserve a declared minimum of background progress. If an overly strict limit fixes editor latency while effectively starving the build, closure is invalid and the state remains OVERCONSTRAINED or REPAIR_POLICY.

10. Negative control defeats one-signal diagnosis

One fixture deliberately drives CPU high while an active quota keeps foreground latency below the SLO. The correct conclusion is not “high CPU means interference.” Classification requires joint evidence: a latency violation, compatible pressure/limit evidence, and a meaningful response to mitigation.

11. Containment is not closure

Killing a background process can immediately restore responsiveness, but that is containment. Closure requires replaying the same workload, or a bounded equivalent, under an explicit policy and showing that both foreground SLO and background progress remain acceptable without the failure returning.

12. Lab classifications

The lab uses NO_FOREGROUND_INTERFERENCE, CPU_INTERFERENCE, MEMORY_INTERFERENCE, IO_INTERFERENCE, MIXED_INTERFERENCE, and INTERFERENCE_UNRESOLVED. If the foreground SLO is not violated, high resource use alone does not open the failure. If latency is violated but pressure evidence is insufficient, keep the diagnosis unresolved.

13. The closure oracle has two primary gates

After a policy change, the evaluator checks at minimum that post_limit_foreground_latency <= SLO and post_limit_background_progress >= declared minimum. It also rejects a new OOM event. This prevents a mitigation that helps only one side of the system from receiving PASS.

14. Lab: eight fixtures and 64 assertions

Eight deterministic fixtures cover a healthy baseline, CPU interference, a CPU-high negative control, memory-pressure failure, I/O transfer failure, mixed pressure, an over-constrained policy, and successful closure. The evaluator emits eight fields per case, giving exactly 64 administrative assertions.

15. Exit checklist and transfer

Before exit, identify the foreground SLO, the background resource evidence, the dominant pressure, the chosen containment, the minimum background-progress bound, and the independent replay that proves closure. In transfer, CPU demand falls while memory reclaim and I/O bursts rise; rebuild the policy from fresh evidence rather than copying the prior answer.