docs(rfc): propose reviewed multi-artifact Dreaming

[Zxf-xufeng]

Which issue or RFC does this PR close?

Proposes a new RFC building on RFC 1510 (Artifact Dreaming). Companion implementation: #1716. Database migration follows #1771, with #1772 as its implementation foundation. No issue is closed by this proposal.

Rationale for this change

Later evidence can invalidate Memory, Profile, Topic Memory, Handoff, Skill, Prompt, and Tag state. Dream needs reviewed proposals that respect each resource's commit contract. Candidate represents a proposed change, including Tag changes that do not create an Artifact Revision. Schema changes must use the shared database migration framework rather than a separate Dream startup migration.

What changes are included in this PR?

• Add Chinese and English RFCs for evidence-driven Dream extensions, deterministic validation, human review, and Family-specific atomic publication. Existing non-Dream automatic generation keeps its activation policy.
• Define six unified /v1/candidates/* operations and typed Artifact/Tag proposals, results, history, and shared Inbox pagination, including Tag submission and revision examples.
• Rename and extend the two existing Candidate business tables to pc_candidate_heads and pc_candidate_versions. Tag approval validates ETag and content baseline without manufacturing a revision.
• Delegate migration execution, baseline recognition, backup/recovery, service lifecycle, and startup readiness to docs(rfc): define unified versioned database migrations #1771. Dream contributes immutable revisions, frozen resources, a schema/API/task impact manifest, and domain postconditions. It adds no separate migration control table and reuses the shared pc_schema_revision(version_num).
• Define the legacy Dream drain policy for unstarted runs, queued retries, running/expired attempts, and terminal history. Do not rewrite frozen prompt/model identities or deadlines; pending Candidates remain reviewable after upgrade. Move the additive Handoff/Prompt processing manifest conversion into the shared revision, preserving ownership mode and automatic-binding history.
• Preserve historical candidates, decisions, evidence, Profile pointers, Dream references, ownership, and outstanding task semantics. Retain registered replaced tables and recovery objects under the unified framework instead of deleting them after startup or migration success.
• Require complete baseline, task, startup, and SQLite/seekdb/OceanBase acceptance before production enablement. feat(db): align migration prototype with single-table RFC #1772's four-table SQLite prototype reports server_ready=false and is not sufficient for a full Dream deployment.
• Specify coordinated OpenAPI, generated clients, SDK/CLI/MCP, integrations, Dashboard, and bilingual website documentation updates in the implementation.
• Preserve exact evidence, bounded execution, Profile settings-only policy snapshots and cursor isolation, complete Topic projections, Handoff review_then_publish capabilities and publication on approval with separate explicit Continue/receiver verification, and Prompt write authority. Trusted evaluation infrastructure remains outside this proposal.

Are there any user-facing changes?

Documentation only; this PR does not enable operations or execute database changes. The design directly replaces /v1/artifact-candidates/* with /v1/candidates/* without aliases or redirects, explicitly declaring an exception to the normal API deprecation period. Release metadata must identify replacement routes, the removal release, and matching minimum Client versions. Unpublished Catalog Change routes and storage require no production compatibility layer.

Existing local and remote databases require explicit migration through the #1771 workflow with stopped writes and coordinated Server/Client upgrades, including A0/A1-only deployments with Tag disabled. Package installation does not migrate data; ordinary startup validates compatibility and performs no schema upgrade. Empty initialization, retained objects, and recovery follow #1771. Database migration does not provide old-API compatibility or make mixed old/new binaries safe.

How was this change tested?

• Cross-checked the migration integration against docs(rfc): define unified versioned database migrations #1771 (cca48f15) and the actual acceptance scope of feat(db): align migration prototype with single-table RFC #1772 (dce0bb9c).
• Checked bilingual consistency, fenced JSON examples, Markdown fence balance, relative document links, and required integration declarations.
• Ran git diff --check and repository pre-commit checks; Python type checking is excluded for this documentation-only change.
• Runtime and database acceptance scenarios are implementation release requirements, not claims of validation performed by this documentation PR.

AI usage statement

OpenAI Codex was used to write and review the bilingual RFC and check documentation consistency.

[hidb4ai]

LGTM