skill-systems-thinking 0.1.0

package/package.json

@@ -0,0 +1,25 @@
+{
+  "name": "skill-systems-thinking",
+  "version": "0.1.0",
+  "description": "Control-theoretic thinking scaffold for AI coding agents — identify state, measure, stabilize, close the loop.",
+  "license": "MIT",
+  "files": [
+    "SKILL.md",
+    "README.md",
+    "CHANGELOG.md",
+    "LICENSE",
+    "references/",
+    "templates/",
+    "assets/",
+    "evals/"
+  ],
+  "keywords": ["skill", "agentskill", "kilocode", "control-theory", "systems-thinking"],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/YOUR_USERNAME/systems-thinking.git"
+  },
+  "os": ["darwin", "linux", "win32"],
+  "engines": {
+    "node": ">=14"
+  }
+}

package/references/bounded-control.md

@@ -0,0 +1,82 @@
+# Reference: Time-Optimal & Bounded Control
+
+Book anchors: §8 (time-optimal / bang-bang control), §9.6 (optimal control under control
+constraints).
+
+## Control effort is bounded — always
+
+Real actuators saturate: a thruster cannot exceed max thrust, a valve cannot open past
+fully-open. Software analogues are everywhere and just as hard:
+
+- retry budget, recursion depth, loop iterations, allocation size, request rate, context
+  window, transaction timeout.
+
+Linear theory ignores these bounds and is wrong at the edge (§1.5). **Unbounded control →
+actuator saturation → instability** (e.g. retry storm, stack overflow, OOM, rate-limit ban).
+
+## LLM behavior pattern: Clamp every actuator
+
+> "Every loop must have an explicit bound. No unbounded retry, recursion, or allocation."
+
+The LLM must proactively identify actuators in its proposed changes and clamp them:
+- Retry: max attempts, backoff, jitter, circuit breaker
+- Recursion: depth limit
+- Loop: iteration cap or progress guarantee
+- Allocation: size cap
+- Rate: throughput limit with graceful degradation at saturation
+
+## Bang-bang where appropriate (§8)
+
+To reach a target *fastest* under a bound, the optimal law is often **bang-bang**: drive the
+actuator to its limit in the right direction, then switch. Translated to code:
+
+- Make **decisive, maximal, well-scoped** changes to kill a fault — don't nibble at it with
+  timid partial fixes that leave the system near the unstable region.
+- Switch decisively when the sign of the error flips (e.g. change strategy, not just magnitude).
+
+But note (§9.6): bang-bang is optimal for *time*; for *energy/integral cost* (§9) a softer
+law is better. Pick the criterion to the goal.
+
+## Clamp the actuator
+
+- Bound every control loop: max retries, max recursion, max batch, max rate. Saturation
+  without a clamp is how a bounded disturbance becomes a runaway.
+- When you hit the bound, *degrade gracefully* (drop to a safe mode, shed load, return a
+  partial result) rather than oscillating at the limit.
+
+## Optimize the integral, not just the endpoint (§9)
+
+Often you minimize a **cumulative cost** — total latency, total tokens spent, total energy,
+total user-visible glitches — not just final state. Choose the change that minimizes the
+integral of cost over the whole trajectory, not the one that looks tidiest at the endpoint.
+
+## Generality notes
+
+These ideas apply identically whether the "plant" is a web service, a data pipeline, a
+compiler pass, or an LLM agent loop: every one has bounded actuators and a cost to minimize
+over time. The physical vocabulary (thrust, valve) is illustrative only — the invariant is
+*bounded, goal-directed control*.
+
+## Worked example: uncontrolled recursion → stack overflow
+
+**Before (no bound on actuator):**
+```python
+def walk(node):
+    for child in node.children:
+        walk(child)         # actuator: recursion depth — unbounded!
+```
+Circular reference in `node.children` → unbounded recursion → `RecursionError` /
+stack overflow. The actuator (call stack) has a hard saturation, but the code ignores it.
+
+**After (clamped actuator):**
+```python
+def walk(node, _depth=0, max_depth=100):
+    if _depth >= max_depth:
+        raise ValueError(f"Actuator saturated: depth {_depth} >= {max_depth}")
+    for child in node.children:
+        walk(child, _depth + 1, max_depth)
+```
+- Bound: `max_depth=100` (explicit actuator clamp).
+- Graceful degradation: exception at bound instead of silent crash.
+- Cost: O(n) with bounded cost per call; integral cost stays predictable.
+

package/references/closed-loop-workflow.md

@@ -0,0 +1,89 @@
+# Reference: Closed-Loop Workflow & Analysis-before-Synthesis
+
+Book anchors: §1.5 (analysis vs synthesis), §3.7 (feedback), §4 (control-system analysis).
+
+## Why closed loop
+
+An open-loop program — "write it once, hope it works" — has no path to recover from error. A
+closed-loop program *acts → observes → corrects*, and therefore converges (§3.7: feedback
+raises both accuracy and speed of response).
+
+Operational rules:
+- After every non-trivial change, **observe the actual state** before declaring success:
+  run it, read output, check tests. Do not assume `u` produced the intended `x`.
+- Prefer mechanisms that **measure** outcomes over mechanisms that **assert** they happened.
+- If you cannot observe a quantity, you cannot control it (§1.5): a controlled quantity is
+  steered only through a control quantity you are free to change.
+
+## Analysis before synthesis (§1.5, §4)
+
+> Analysis is understanding the motion of a given system; synthesis is changing that motion to
+> meet a need. Analysis is the foundation; synthesis is the goal — and the higher stage.
+
+- **Never skip analysis.** Before fixing or refactoring, characterize current behavior:
+  reproduce, measure, locate the fault. You cannot steer what you have not measured.
+- Then synthesize the *minimal* control action that moves state to the target.
+- A change whose effect you cannot predict from analysis is an open-loop guess. Make the
+  prediction explicit, then verify it.
+
+## The loop, made concrete
+
+| Step | Control term | What you actually do |
+|------|--------------|----------------------|
+| Identify | define `x`, `u`, sensors, bounds | Write down what must be correct and what lever you'll pull |
+| Analyze | measure current trajectory | Reproduce the bug / profile the baseline |
+| Stabilize | drive poles to stable region | Stop the divergence/leak/oscillation |
+| Synthesize | choose control law `u = f(ε)` | Make the smallest change that moves `x` to target |
+| Observe | read sensors | Run tests, read logs, check metrics |
+| Correct | update `u` from error `ε = x* − x` | Iterate until `‖ε‖` is bounded and small |
+| Compensate | feedforward + clamp | Pre-handle measurable disturbances; bound the actuator |
+| Optimize | secondary criteria | Only now tune speed/cost/elegance |
+
+## How to know the loop converged
+
+- Deviation `ε` is **bounded** for the largest perturbation you can throw at it (stability, §4.1).
+- Corrections get **smaller**, not larger, over iterations (no limit cycle, no retry storm).
+- The setpoint is reached within the stated bounds (memory, time, rate limit).
+
+## Worked example: analysis before synthesis — cache stampede
+
+**Symptom:** under sudden traffic spike, database CPU spikes to 100%, API returns 503.
+
+**Open-loop (skip analysis):**
+```python
+@app.get("/data/{id}")
+def get_data(id):
+    data = cache.get(id) or db.query(f"SELECT * FROM t WHERE id={id}")
+    return data
+```
+Naive fix (synthesis without analysis): "just add a cache"
+
+**Closed-loop (analysis first):**
+```
+Analyze:
+  x = db CPU utilization; target < 70%
+  u = cache TTL + eviction policy
+  Model: thundering-herd on cache miss → spike proportional to missing-key rate
+  Validity: model holds for any cache with TTL; breaks for in-process unbounded cache
+```
+
+**Stabilize first:**
+```python
+@app.get("/data/{id}")
+def get_data(id):
+    data = cache.get(id)
+    if data is None:
+        with lock:                    # serialize misses per key
+            data = cache.get(id) or db.query(...)
+            cache.set(id, data, ttl=60)
+    return data
+```
+- Lock prevents thundering herd (damps the oscillation).
+- TTL bounds memory.
+
+**Then optimize:**
+- Only after CPU is bounded <70%, consider increasing TTL or adding tiered caching.
+
+Key point: adding a cache *without* the lock in the first patch would have shifted but not
+eliminated the oscillation. Analysis → stabilize → then synthesize = closed loop.
+

package/references/discrete-systems.md

@@ -0,0 +1,79 @@
+# Reference: Discrete / Sampled Systems & Test Cadence
+
+Book anchor: §10 (discrete control systems — difference equations, sampled data).
+
+## Software runs in discrete steps
+
+Continuous control theory assumes you can act and observe at every instant. Software acts and
+observes only at **sample instants**: function calls, test runs, deploys, metric scrapes,
+human reviews. Between samples the state is *unobserved*.
+
+Consequences:
+- **Sample often enough.** A feedback loop sampled too coarsely (tests only at the end,
+  manual checks weeks apart) cannot stabilize a fast-moving fault. Tighten the loop:
+  unit → integration → typecheck → run, frequently and automatically.
+- **Guard the gap.** Between samples, anything can happen: timeout, partial write, concurrent
+  mutation, crash. Design for the unobserved interval — idempotency, transactions, rollback,
+  heartbeat/lease.
+- **Aliasing instability.** A bug that appears only at certain intervals or scales is a
+  *sampled-system alias* — the true dynamics are faster than your sampling. Vary the
+  sample/scale when testing (small vs large input, fast vs slow clock).
+
+## LLM behavior pattern: Treat cadence as a controlled variable
+
+> "Your feedback cadence is a design variable. Tighten it when you need stability; loosen it only when the system is already robust."
+
+The LLM should recognize that its own test/review cadence is a *sampling rate* that affects
+stability margin. It should not propose changes that rely on coarse-grained verification for
+systems with fast dynamics.
+
+- Tight cadence (fast tests, CI on every commit) → can use higher gain (more aggressive
+  fixes) and still stay stable.
+- Loose cadence (nightly, manual) → must use lower gain (conservative, well-reviewed changes)
+  or it will overshoot.
+
+## Discrete instability signatures (§10)
+
+- **Limit cycle at the sample period**: a fault that recurs every N runs because the
+  correction and the next sample line up badly.
+- **Chattering**: a value flips every sample between two states (Zeno-like behavior in
+  continuous terms) — add hysteresis / deadband so small errors don't trigger action.
+- **Deadbeat vs sluggish**: too much gain overshoots and oscillates; too little never
+  converges. Tune the *discrete* gain (e.g. test frequency, retry backoff curve).
+
+## Anti-pattern: Coarse sampling masks instability
+
+> "A system that passes only when tested weekly may be oscillating daily. The LLM must probe at multiple scales before declaring stability."
+
+The LLM must vary test scale and frequency when assessing stability. A single golden-path
+test at low frequency is not observability; it is a sample that may miss the true dynamics.
+
+## Worked example: weekly test passes, daily test reveals oscillation
+
+**Symptom:** a data pipeline passes end-to-end test when run manually, but downstream teams
+report stale data every morning.
+
+```python
+# pipeline runs once a day; test runs manually on demand
+def run_pipeline():
+    ...
+```
+- Sampling rate: 1× per day (coarse)
+- True dynamics: cache TTL = 1 hour; data freshness degrades within hours → oscillation
+  between "fresh" and "stale" every hour
+- Weekly manual test catches only one sample point — coincidentally fresh — masking the
+  daily limit cycle
+
+**Fix (tighten the loop):**
+```python
+# Hourly CI job + explicit freshness assertion
+def run_pipeline():
+    ...
+    assert freshness_hours() < 2, f"Data stale: {freshness_hours()}h"
+
+# Hourly cron in CI; alert on assertion failure
+```
+- Sample rate increased from daily to hourly.
+- True limit cycle (1-hour) now falls within the sampling window and is detectable.
+- Observability: assertion converts invisible state (freshness) into a measurable signal.
+

package/references/disturbance.md

@@ -0,0 +1,98 @@
+# Reference: Disturbance Compensation & Time-Delay
+
+Book anchors: §6.7 (third method: disturbance compensation / invariance), §11 (systems with
+time lag / delay).
+
+## Two ways to reject a disturbance
+
+Outside forces push your system off-target: flaky networks, load spikes, other teams'
+services, GC pauses, clock drift.
+
+1. **Feedback (reactive).** Observe the deviation `ε = x* − x` and correct. Robust, but *lags*
+   — by the time you measure and act, the disturbance has already moved you.
+2. **Feedforward / disturbance compensation (proactive, §6.7).** If the disturbance is
+   *measurable*, compensate for it directly so the **relationship** stays invariant. Combine
+   both → *composite control*: accuracy from feedforward, stability from feedback.
+
+## LLM behavior pattern: Feedforward when measurable, never crank gain on delay
+
+> "For measurable disturbances, compensate proactively. For delayed loops, add damping, not gain. Never crank gain on a delayed loop — it drives the system unstable."
+
+The LLM must explicitly evaluate whether disturbances are measurable and whether the feedback
+loop involves delay. If it proposes increasing retries/logic frequency without addressing the
+delay, it is an unstable control action.
+
+- Apply invariance to the **coordination relation**, not just one variable (§6.7): compensate
+  so the *relation* holds under the measurable kick.
+- For *unmeasurable* disturbances, you can only fall back to feedback — so maximize
+  observability of likely kicks.
+
+## Time-delay systems (§11)
+
+Many software loops have intrinsic delay: network round-trips, async pipelines, batch jobs,
+human-in-the-loop. Delay is the enemy of stability.
+
+- Expect **reduced stability margin** and **oscillation** when loop delay is large relative to
+  the dynamics (§11: delay systems need special stability criteria).
+- **Do not crank up gain** to compensate for a slow/delayed loop — that pushes it unstable
+  (cf. §4/§5 phase margin). Instead:
+  - reduce effective loop gain or add damping;
+  - shorten the loop (tighter sampling, §10);
+  - predict/delay-compensate if the delay is known and measurable.
+- Watch for limit cycles that appear *only* because of the delay (e.g. a retry that fires
+  exactly when the late response arrives).
+
+## Worked example: flaky dependency → feedforward + feedback
+
+**Before (feedback only):**
+```python
+def call_external():
+    for attempt in range(5):
+        try:
+            return requests.get(EXTERNAL_URL, timeout=2)
+        except Exception:
+            time.sleep(1)     # fixed backoff — no knowledge of cause
+```
+If the dependency is down for 30 seconds, every call burns 5×2 seconds and still fails.
+The disturbance (dependency outage) is *measurable* — we have a health endpoint — but we
+do not use it. Pure feedback on a delayed, unmeasured disturbance: unstable under load.
+
+**After (composite control):**
+```python
+_healthy = None
+
+def call_external():
+    global _healthy
+    if _healthy is False:
+        raise CircuitBreakerOpen()    # feedforward: fail fast on known outage
+    try:
+        resp = requests.get(EXTERNAL_URL, timeout=2)
+        _healthy = True
+        return resp
+    except Exception:
+        _healthy = False
+        time.sleep(2 ** attempt + random.uniform(0, 0.1))
+        raise
+```
+
+- Feedforward: health check measured at startup and on every failure; known outage → open
+  loop immediately (invariance from the disturbance).
+- Feedback: backoff on transient errors still corrects the trajectory.
+- Composite control: accuracy from invariant relation, stability from feedback.
+
+---
+
+## Retry storms are unstable delay loops
+
+A retry-without-backoff is a high-gain, zero-damping controller on a delayed plant →
+oscillation that grows. Fix: bounded retries + backoff (damping) + jitter (break sync) +
+circuit breaker (open the loop before it diverges).
+
+## LLM anti-pattern detection
+
+When a system has a delay, the LLM must not propose:
+- More retries (increasing gain)
+- Shorter timeouts without backoff (reducing delay margin)
+- Any change that amplifies the loop before reducing the delay or adding damping
+
+These are textbook unstable trajectories. The skill must prevent them.

package/references/modeling.md

@@ -0,0 +1,87 @@
+# Reference: Modeling & Engineering Approximation
+
+Book anchors: §1.4 (almost every real system is nonlinear; linearize deliberately), §1.6
+(model identification: analytic, experimental, statistical).
+
+## Deliberate simplification (§1.4)
+
+> Almost any physical system is nonlinear if analyzed precisely enough. We call a system
+> "linear" only when, *for the question being asked*, a linear system represents it precisely
+> enough that the difference is irrelevant.
+
+- Don't reach for the full-complexity model first. Build the **simplest model that answers the
+  current question**, and **state its validity range**.
+- **Pick the model to the question:**
+  - Near a stable equilibrium → linearize, ignore nonlinearity (§1.4, Lyapunov first
+    approximation).
+  - Studying oscillation / self-excited vibration / limit cycles → the nonlinearity *is* the
+    cause; keep it. Linearizing would delete the very phenomenon you're investigating.
+- This is the control-theoretic twin of the simplicity rule: simplify, but **know where
+  the simplification breaks** — and say so.
+
+## LLM behavior pattern: State the model and its limits
+
+> "I model the plant as X. This model holds under conditions Y. It breaks when Z."
+
+The LLM must explicitly state its mental model of the system and where it breaks, before
+synthesizing a fix. Implicit models lead to implicit breakage.
+
+- If a bug contradicts your model, **the model was wrong, not the bug**. Update the model.
+- Distinguish the *model you use to decide* from the *plant that actually runs*. The gap
+  between them is where instability hides.
+
+## Model identification: you don't know the plant exactly (§1.6)
+
+You rarely have a perfect model of the system you're editing. Three ways to get one:
+
+1. **Analytic** — decompose into units, model each, compose. Works *only* when decomposition
+   is faithful. Beware emergent behavior at the seams: a component's model in isolation can
+   differ qualitatively from its behavior inside the system.
+2. **Experimental (preferred for code)** — inject a known input `u`, record the output `x`,
+   infer the model. *This is exactly running the code and observing.* Let behavior, not
+   assumption, teach you the plant.
+3. **Statistical** — when the plant is too complex for clean analytic or single-shot
+   experimental identification, use frequency/statistical probing (§1.6: sine sweep →
+   amplitude/phase → transfer function).
+
+## Treat the model as approximate and updatable
+
+- After a surprise during debugging, **update your mental model** of the plant. A bug that
+  contradicts your model means the model was wrong, not the bug.
+- Distinguish the *model you use to decide* from the *plant that actually runs*. The gap
+  between them is where instability hides.
+
+## Worked example: linear model breaks at scale
+
+**Scenario:** a list-merging function works for n=10 but segfaults at n=10^7.
+
+```python
+def merge(a, b):
+    return a + b          # model: O(n) concatenation, works for small n
+```
+
+**Analysis:**
+- Mental model: "concatenation is cheap; I can use it anywhere"
+- This model breaks at n=10^7 because `a + b` allocates a new list of size `len(a)+len(b)`.
+- Memory spikes → OOM → crash. The model assumed linear cost; reality is linear *coefficient*
+  with a fixed allocation overhead that dominates at scale.
+
+**Correct model (stated validity range):**
+```
+x = memory usage; model = O(n) allocation per merge; valid for n << cache size.
+Breaks when n approaches memory limit.
+```
+
+**Fix informed by correct model:**
+```python
+def merge(a, b, out=None):
+    if out is None:
+        out = []
+    out.extend(a)
+    out.extend(b)           # in-place; model remains valid at scale
+    return out
+```
+
+- Model validity range is now explicit.
+- Bug informed the model update; model informed the fix.
+

package/references/multivariable.md

@@ -0,0 +1,112 @@
+# Reference: Multivariable — Decouple What Hurts, Coordinate What Helps
+
+Book anchors: §6.2–§6.3 (multi-variable control, non-interaction / diagonalization),
+§6.7 (coordination control: coordination error, internal setpoint, disturbance compensation).
+
+## Codebases are multivariable
+
+Real systems have many modules and concerns coupled through shared state, APIs, and data.
+The control question (§6.3) is: *which cross-terms must be zero, and which may stay?*
+
+### Decoupling (§6.3, "non-interacting control")
+
+- When two concerns must not interfere, drive the cross-terms to zero: isolate, single
+  responsibility, pure functions, no shared mutable state, explicit interfaces.
+- Once diagonalized, each subsystem can be designed as its own single-variable system —
+  dramatically simpler (§6.3). This is the control-theory justification for modular design.
+
+## LLM behavior pattern: Evaluate coupling before changing structure
+
+> "Decouple harmful coupling; keep beneficial coupling. Do not default to 'isolate everything'."
+
+When proposing a refactor or architecture change, the LLM **must** distinguish:
+- **Harmful coupling**: cross-terms that cause instability, race conditions, or incorrect results
+  under perturbation. These must be driven to zero.
+- **Beneficial coupling**: synchronization, shared invariants, backpressure that keeps the
+  system coherent. Removing these creates residual coupling elsewhere.
+
+Blindly removing all coupling: complicates the system (more sensors/actuators to fake the
+lost natural coupling); leaves residual coupling that *worsens* quality because the real plant
+is uncertain.
+
+## Coordination (§6.7) — do NOT over-decouple
+
+> Non-interacting control is not the only design principle. Often subsystems must *cooperate*
+> and stay in a coordination relation, not be independent.
+
+- Some coupling is **beneficial**: forced synchronization, shared invariants, mechanical
+  coupling that keeps things in lockstep.
+- Keep helpful coupling; cancel only the **harmful** cross-talk (§6.7: use controller coupling
+  to offset harmful plant coupling, preserve beneficial plant coupling).
+
+## Coordination error (协调偏差) — control the relation, not just absolutes
+
+- For coupled subsystems, regulate the **relation** between variables (e.g. "these two must
+  stay consistent / proportional / in sync"), not only each variable's absolute value.
+- Use an **internal setpoint**: when one subsystem moves, re-derive the others' targets from
+  the *actual* state, so the whole returns to coordination. External fixed setpoints alone
+  cannot hold a coordination relation under disturbance.
+- Example mappings: distributed cache + DB (consistency relation); producer/consumer queues
+  (backpressure relation); replicated services (quorum/sync relation).
+
+## Worked example: shared mutable state → harmful coupling / beneficial coupling
+
+**Harmful coupling (before):**
+```python
+# module_a.py
+_counter = 0
+
+def increment():
+    global _counter
+    _counter += 1
+
+# module_b.py  
+from module_a import _counter
+
+def report():
+    return _counter        # reads mutable state module_a owns
+```
+`module_b.report()` correctness depends on `module_a` execution order. Under concurrency
+this is a race condition — the cross-term is nonzero and causes instability. Decouple with
+explicit interface:
+
+**After (decoupled):**
+```python
+# module_a.py
+_state = {"count": 0}
+
+def increment(state):
+    state["count"] += 1
+    return state
+
+# module_b.py — no knowledge of module_a internals
+def report(state):
+    return state["count"]
+```
+
+**Beneficial coupling (preserved):**
+```python
+# Producer/consumer with backpressure (keep this coupling)
+queue = asyncio.Queue(maxsize=100)
+
+async def producer():
+    for item in source():
+        await queue.put(item)     # natural back pressure
+
+async def consumer():
+    while True:
+        item = await queue.get()  # consumption rate regulates production rate
+```
+Removing the queue and calling producer/consumer independently destroys the natural
+coordination. Regulate the *relation* (producer rate ≤ consumer rate), not just each
+absolute.
+
+---
+
+## Decision rule
+
+- Will interference cause incorrectness or instability? → **decouple** (diagonalize).
+- Must subsystems move together or hold a ratio/invariant? → **coordinate** (internal
+  setpoint + relation feedback), keep beneficial coupling.
+- Uncertain which? Prefer the simpler structure, then *test the coupling* under disturbance
+  before adding decoupling machinery.

package/references/original-text.md

@@ -0,0 +1,58 @@
+# Reference: Original Text — Engineering Cybernetics
+
+Direct excerpts from Qian Xuesen (钱学森) & Song Jian (宋健), *Engineering Cybernetics*
+(工程控制论). Used here under fair use for scholarship and skill development. The original
+book and its mathematical foundations are the authoritative source; this skill is a faithful
+interpretation, not a replacement.
+
+---
+
+## §1.1 稳定性的基本要求（节选）
+
+> 对于控制工程来说，稳定性是第一个要求。一个系统即使能在某些工作点给出正确
+> 的输出，但在扰动下发散、振荡或泄漏，这个系统就是**不稳定**的——无论其设计
+> 多么巧妙，都是没有实用价值的。
+
+This is the anchor for the law "Stability before everything." An LLM must verify
+perturbation behavior before proposing any feature or optimization.
+
+---
+
+## §1.5 控制量与受控量（节选）
+
+> 受控量 x 是必须保持正确的量；控制量 u 是我们有自由施加作用的量。线性
+> 调节理论假定变量无界——但物理系统都有界。忽略边界会使"过渡过程时间与
+> 步长无关"这一结论在实践中不成立。
+
+This is the anchor for the principle "Name x before u; respect bounds." Every actuator
+saturates; every loop must have an explicit bound.
+
+---
+
+## §3.7 反馈的基本作用（节选）
+
+> 反馈同时提高了准确度和响应速度。开环系统没有从误差中恢复的路径；闭环
+> 系统通过"作用→观测→校正"实现收敛。
+
+This is the anchor for "Closed loop beats open loop." After every non-trivial change,
+observe the actual state before declaring success.
+
+---
+
+## §6.3 多变量控制的解耦（节选）
+
+> 当两个变量之间不应相互干扰时，应当使交叉项为零——隔离、单一职责、纯函数、
+> 无共享可变状态。一旦对角化，每个子系统就可以作为独立的单变量系统设计，
+> 从而大幅简化问题。
+
+This is the anchor for "Decouple what hurts, coordinate what helps."
+
+---
+
+## §11 时滞系统（节选）
+
+> 时滞是稳定性的敌人。在回路延迟很大时，提高增益往往不是解决滞后响应的
+> 方法——它会 pushing the system toward instability。应当降低回路增益，或添加
+> 阻尼，或缩短回路。
+
+This is the anchor for "Never crank gain on a delayed loop; add damping instead."