fix(migration): update outbound_capabilities §3 to Sprint 23 P1 default-open semantics (#242 forward-link)

[suzuke]

Summary

Cross-team Sprint 23 P1 PR #242 on agend-terminal merged 12:34:05Z and reversed the Sprint 22 P0 fail-closed default for InstanceConfig.outbound_capabilities to default-open per operator philosophy ("absent ≡ all permitted"). Phase A follow-up PR #65's §3 content is now stale on three load-bearing points; this PR corrects them.

Three changes (per dev-impl-1 + dev-lead)

1. Tri-state framing reverse

• Old (fix(migration): add outbound_capabilities to fleet.yaml schema diff (#230 forward-link) #65): None (absent) → FATAL warn-but-permit one daemon cycle (Sprint 22 P0) → hard parse error (Sprint 23).
• New: None (absent) → all ops permitted (default-open). Full decision matrix:

  YAML	Behaviour
  key absent	all ops permitted (default-open)
  [reply, react]	only listed ops permitted
  []	all rejected (explicit opt-out, retained from Sprint 22 P0)

2. FATAL log expectation removed

The gate_outbound_for_agent warning logic was removed in #242 along with the original fail-closed default. The "Symptom when key is absent" subsection (with the tracing::error! line and the mutex-guarded HashSet rate-limit description) is removed entirely.

3. general auto-inject paragraph removed

Built-in coordinators now inherit default-open like every other instance — no special [reply, react, edit, inject_provenance] injection. The forward link to bootstrap::fleet_normalize::auto_create_general (which may be refactored upstream per #242) is no longer cited.

Threat-model distinction made explicit (per ts-lead spec)

The new §3.3 heading is "…with a deliberately-different default than user_allowlist" and the section now includes a 2-row alignment table contrasting the two gates:

Gate	Scope	Default	Threat model
channel.user_allowlist (High-friction #1)	per-channel, channel ingress	fail-closed	open default is one credential leak away from internet-driven fleet abuse; silent operator regression possible
outbound_capabilities	per-instance, per-op outbound	default-open	closed default forces over-specification without a corresponding cascade-attack risk

Operator reading the doc sees the deliberate design split, not an inconsistency. The two gates are aligned with dev-team's same intent — both retain their original threat-model defaults.

Migration action

outbound_capabilities is now optional for operator-authored instances; the YAML example in the section shows three patterns:

worker-a:
  # outbound_capabilities omitted — defaults to all ops permitted (TS-equivalent)
worker-b:
  outbound_capabilities: [reply, react]      # explicitly restrict to these ops only
worker-c:
  outbound_capabilities: []                  # explicit lockdown

Scope (per ts-lead constraints)

• ✅ §3 outbound_capabilities row (High-friction Opencode Reply Not Delivered to Telegram #3)
• ✅ §3 Rust-only fields table cell (also part of §3)
• ⚠️ Other sections (§1, §6, §7) intentionally NOT touched — will surface stale references to ts-lead in the report for a follow-up decision.
• Forward link to docs/MIGRATION-OUTBOUND-CAPS.md preserved (upstream already updated per dev-impl-1 to reflect Sprint 23 P1 semantics).

Stats

• 2 files changed, 48 insertions(+), 40 deletions(-) (deletions of stale FATAL/auto-inject paragraphs + addition of decision matrix + threat-model alignment table)
• 1:1 zh-TW mirror

Reviewer dispatch

• ts-reviewer — full_review: writing quality, threat-model articulation clarity, anchor preservation, zh-TW parity, alignment with the existing High-friction feat: inject fleet context system prompt into CCD instances #1 / fix: prevent topic_id from being misused as reply thread_id #2 voice.
• dev-reviewer-2 (cross-team) — scope_conformance: Sprint 23 P1 semantics fidelity vs PR #242 (decision matrix accuracy, removal-of-FATAL-log claim, removal-of-auto-inject claim), forward-link Sprint-23-P1-section validity.

🤖 Generated with Claude Code