docs(rfc): define goal capability portfolio

[huangruiteng]

Problem and resulting behavior

LoopX has a capability catalog, Agent-context hooks, connector inventory, external-evidence planning, Decision Context, Explore and reward memory, but a new Agent still lacks one durable Goal-level contract for selecting, composing, evaluating and retiring those pieces. Connector registration/readiness is also easy to confuse with coverage, freshness, parent admission or decision value.

This RFC proposes a Goal-scoped Capability Portfolio with four typed records: catalog reference, Goal adoption, composition plan and use/effect receipt. It defines a connector lifecycle from discovery through bounded trial, qualification, degradation and retirement; reuses before_plan, before_delegate and after_delegate_result; and keeps configuration, authority, evidence, Explore and memory with their existing owners.

Scope and relationship to existing work

• bilingual English/Chinese normative RFC and RFC-index entry
• aligns with the S8 capability roadmap and TypeScript transaction owner
• treats feat(capability): add auditable external evidence lifecycle #4813 as the external-evidence M1 prerequisite instead of duplicating it
• requires one finance and one non-finance effect trial before promotion
• grants no installation, permission, protected-effect or trading authority
• frontend and Lark share the same future public projection; they are M5 companion work, not a second state owner

Validation

• uv run --extra test python examples/docs-governance-smoke.py — passed
• git diff --check origin/main...HEAD — passed
• author and committer identities verified as GitHub noreply; DCO sign-off present

The system Python 3.9 cannot import existing @dataclass(slots=True) code, so the documentation smoke was run in the repository's pinned uv Python 3.13 environment.