diff --git a/.ciagent/CHECKPOINT.json b/.ciagent/CHECKPOINT.json
index 5f5350b..69e0d94 100644
--- a/.ciagent/CHECKPOINT.json
+++ b/.ciagent/CHECKPOINT.json
@@ -1,19 +1,14 @@
 {
   "phase": 0,
-  "stage": "specify",
+  "stage": "clarify",
   "milestone": "v0.11",
   "milestone_slug": "production-hardening",
   "phase_role": "pre_execution",
   "attempts": 0,
-  "updated_at": "2026-08-07T00:00:00Z",
+  "updated_at": "2026-08-07T00:01:00Z",
   "milestone_complete": false,
   "previous_milestone": "v0.10",
   "research_docs_ingested": 5,
-  "locked_decisions": {
-    "Q1": "A",
-    "Q2": "C",
-    "Q3": "A",
-    "Q4": "A",
-    "Q5": "A"
-  }
+  "locked_decisions": {"Q1": "A", "Q2": "C", "Q3": "A", "Q4": "A", "Q5": "A"},
+  "clarifications": {"C1": "hybrid-default-fresh-migrate-existing", "C2": "thin-wrapper", "C3": "drain-reschedule", "C4": "cooldown-on-success-only", "C5": "chain-plus-live-probe"}
 }
diff --git a/.ciagent/CLARIFY_v0.11.md b/.ciagent/CLARIFY_v0.11.md
new file mode 100644
index 0000000..03a8ca3
--- /dev/null
+++ b/.ciagent/CLARIFY_v0.11.md
@@ -0,0 +1,88 @@
+# CLARIFY v0.11: Production Hardening
+
+**Status**: resolved (full autonomy, 2026-08-07). All 5 clarifications
+resolved with the operator's locked decisions (Q1=A, Q2=C, Q3=A,
+Q4=A, Q5=A) and the research-ingestion synthesis. No open questions
+remain for Phase 0.
+
+## Resolved clarifications
+
+### C1 — Ingress default binding (resolved)
+
+**Question**: Is `127.0.0.1:8443` + nft the *shipped default*, or is the
+v0.8 behavior (`:443` on Traefik) still the default and hybrid is opt-in?
+
+**Decision**: R-017 makes the hybrid the **default for fresh `orca init`**
+(new clusters). Existing v0.9/v0.10 clusters get an opt-in migration path
+via `orca upgrade` (REQ-115), which handles the Traefik binding cutover
+from `:443` to `127.0.0.1:8443`. This is a behavioral change for existing
+operators but it ships in a controlled migration phase (P14a), not as a
+surprise default flip.
+
+**Affected REQs**: REQ-100 (Traefik binding), REQ-115 (`orca upgrade`).
+**Affected phase**: P14a (migration), P15.5 (new default).
+
+### C2 — `orca upgrade` scope (resolved)
+
+**Question**: Is `orca upgrade --to-vX` (a) a thin wrapper around
+`install.sh` + `orca restore` (binary upgrade only), or (b) a full
+cluster-rolling-upgrade orchestrator (drain → upgrade binary → restart →
+next node)?
+
+**Decision**: **(a) thin wrapper for v0.11**. Full cluster-rolling-upgrade
+(b) defers to v1.x. The thin wrapper handles the R-017 binding cutover
+(REQ-115) for existing clusters. A full rolling-upgrade orchestrator is a
+v1.x concern (it requires P05 drain + P09 syncthing + P14c mixed-version
+tolerance to be production-tested first).
+
+**Affected REQs**: REQ-115.
+**Affected phase**: P14a.
+
+### C3 — `orca job migrate` semantics (resolved)
+
+**Question**: Does `orca job migrate --to <node>` (a) drain+reschedule
+(uses P05 drain + P06 alloc history), or (b) live-migrate with storage
+replication (uses P09 syncthing, much harder)?
+
+**Decision**: **(a) drain+reschedule for v0.11**. It composes existing
+P05/P06 work. Live-migrate with storage replication (b) is a v1.x concern
+(requires P09 syncthing replication to be production-tested + a
+storage-replication-aware scheduler).
+
+**Affected REQs**: REQ-116.
+**Affected phase**: P05.
+
+### C4 — Remediation cooldown refinement (resolved, design refinement)
+
+**Question**: Doc 5's D-232 cooldown (5-min) should not apply on transient
+remediation *failures* (SSH down, render tree missing) — only on
+*successful* remediation. Else a 30s network blip blocks re-remediation
+for 5 min.
+
+**Decision**: **Refine D-232**: cooldown applies only on *successful*
+remediation; transient failures (SSH down, render tree missing, applier
+non-zero exit) retry on the next aggregator tick (10s) without entering
+cooldown. This is baked into REQ-108 and the D-232 rationale in
+PROJECT.md.
+
+**Affected REQs**: REQ-108.
+**Affected phase**: P10.
+
+### C5 — `orca doctor mTLS` depth (resolved)
+
+**Question**: Does `orca doctor mTLS` just verify the trust chain (CA →
+server cert → workload SVIDs exist + not expired), or does it also do a
+live mTLS handshake probe to each peer?
+
+**Decision**: **Both**. Chain verification is cheap (local file reads +
+cert parsing); live probe reuses P01 (metrics endpoint) + P01.5 (SPIFFE
+spike) infrastructure. The doctor check reports both: chain integrity
+(static) + live handshake (dynamic). A failed live handshake with a valid
+chain indicates a network/config problem, not a cert problem.
+
+**Affected REQs**: REQ-118.
+**Affected phase**: P15.5.
+
+## Open questions
+
+None. All 5 clarifications resolved. Phase 0 proceeds to RESEARCH.