feat(dream): expand reviewed artifact and tag revisions

[Zxf-xufeng]

Which issue or RFC does this PR close?

Implements the Dream domain expansion in #1715 across A0/A1, B1, B2, and C. Database upgrade responsibilities follow #1771. This PR supplies the Dream contribution; the complete migration framework and production registration remain in #1772. Trusted evaluation services and evaluation approval gates are outside scope.

Rationale for this change

New evidence can correct existing knowledge, instructions, configuration, or classification. Dream proposes reviewed changes for Memory, Profile, Topic Memory, Handoff, managed Skill, Prompt, and Tag. Every proposal remains pending until an authorized reviewer approves its exact version against the current resource baseline. Existing automatic generation retains its own policy.

Existing databases must not be changed implicitly when a Server, Worker or SDK opens them. Dream supplies its schema changes and domain checks to the unified migration framework instead of owning another startup migration runner.

What changes are included in this PR?

• Extend the existing v1 Dream submission and lookup contract with typed operations, exact evidence, bounded execution, Family routing, audit metadata, and conditional publication.
• Replace Artifact-named review routes with six /v1/candidates/* operations. Artifact and Tag proposals share pc_candidate_heads and pc_candidate_versions, immutable history, one Inbox ordering and pagination, and typed approval results. Tag approval checks both ETag and content basis without fabricating an Artifact Revision.
• Preserve Memory entry identity, Profile Source-window isolation and settings-only policy snapshots, complete Topic retrieval projections, and Handoff objective validation. Handoff advertises review_then_publish; approval publishes a revision eligible for explicit continue_latest(); it does not execute Continue, acknowledge receipt, or perform work.
• Support instruction-only managed Skill revisions without installing or executing packages, and Prompt revisions with key-specific schemas, publication authority, frozen in-flight inference and monotonically versioned rollback.
• Suppress duplicate proposals within one Scope and principal, rechecking evidence and the actual candidate version before reuse. Keep the durable limit of four consecutive explicit Dream attempts before runnable Source work.
• Remove the Candidate startup migrator, Dream's startup column/index repair, and automatic Processing manifest upgrades. All three database profiles run read-only Dream preflight before business initialization. Legacy structures require explicit maintenance; partial versioned bundles cannot become a Server database through create_all.
• Supply frozen Candidate SQL, a historical Dream task schema, a release-impact manifest, and connection-bound transformation/verification functions for the shared framework. Preserve historical candidates, Profile pointers, terminal Dream payloads, identities, idempotency, ordinary Processing work and retained recovery copies. Require queued/running historical Dream runs to finish with the old runtime before migration; never silently change their frozen prompt/model contract, retries or deadlines. Transform Handoff/Prompt processing bindings in the same explicit migration while preserving ownership mode and automatic-binding history. Add no Dream-specific migration control table or runner.
• Update SDK/CLI/MCP, integrations, Dashboard and bilingual usage documentation. RFC documents remain in the separate docs(rfc): propose reviewed multi-artifact Dreaming #1715 branch.

Are there any user-facing changes?

The six /v1/artifact-candidates/* routes are removed directly, without aliases or redirects, as the explicit release exception in #1715. Clients must upgrade with the Server. Unpublished Catalog Change routes/tables have no production compatibility requirement. Extended Dream types use X-PowerContext-Dream-Contract: 2; this header does not restore removed Candidate routes.

Production database upgrade remains gated on #1772. The contribution manifest is deliberately unregistered until the complete historical Server baseline, actual revision chain, release/client versions, task checks, startup readiness and SQLite/seekdb/OceanBase acceptance are available. #1772's four-table SQLite prototype is not sufficient. This branch rejects old Dream storage with migration_required and versioned databases with migration_framework_not_ready; it does not offer a fallback startup upgrade. Fresh development databases and existing complete unversioned development schemas remain usable for domain verification.

Operators stop new Dream admissions and let the old workers drain before stopping all writers. Pending Candidates do not need to be decided before upgrade. Unfinished runs block with dream_tasks_require_drain; unknown processing manifests block before DDL with unknown_processing_manifest.

The framework owns locks, backup policy, transaction boundaries, revision tracking in pc_schema_revision, interruption recovery and cleanup. Dream's retained snapshots survive normal startup and review. Its copy-comparison validator runs during stopped-write migration, not after ordinary reviews legitimately change active data.

How was this change tested?

• Focused Dream, migration, review transport, Processing composition and intent regressions: 173 passed, 95 skipped. Covers legacy queued/retry/running/expired tasks blocking planning and migration without writes, terminal task preservation/replay, explicit manifest conversion, startup rejection without repair, interruption rollback, Candidate history and Handoff publication capabilities.
• make check: passed, including lock consistency, pre-commit hooks, core/integration type checks and 29 integration manifest tests.
• make contract-test: 48 passed, including generated Python/JavaScript API consistency.
• git diff --check: passed.

SQLite transformation tests use real temporary databases and domain reads/workers. They do not establish full framework or production upgrade acceptance. Real seekdb/OceanBase migration and recovery acceptance remain in #1772; skipped tests and backend doubles are not counted as that evidence. The controlled generation tests verify behavior and transactions, not model-quality improvement.

AI usage statement

OpenAI Codex was used to implement and review the changes, update documentation, and write and run regression tests. Backend and framework acceptance limits are stated above.

[PsiACE]

The startup migration logic now handles table renames and constraint changes. Could we evaluate a unified, versioned migration approach, such as Alembic, in a separate follow-up? Given this PR’s size, I’d keep that evaluation and integration outside its scope.

[hidb4ai]

Reviewed ff8fd24. Two reproducible issues remain in Dream generation validation and published Skill readback; details inline.

[hidb4ai]

[P1] Align target evidence handling with the generation contract

The new target rejection prevents valid revisions from reaching review. With the configured qwen3.7-plus, both revise_profile and revise_tags returned structurally valid, source-supported proposals with the target ID plus an independent correction Source in evidence_ids; both runs then failed with invalid_generation_output. Replaying the captured outputs fails unchanged, while removing only the target ID allows candidate creation and approval. The projection does not expose node roles, and the prompt asks for evidence IDs actually used without excluding the target. Make the generation and validation contracts agree while still requiring independent supporting evidence.

[hidb4ai]

[P2] Preserve direct Memory provenance in Skill reads

revise_skill can now publish direct Memory citations, but skill_response() still hard-codes memory_citations=[]. Using a controlled Dream output with real OceanBase, I approved Skill revision 2 with one selected Memory entry: the Candidate, native Skill read and generic Artifact read retained the citation, while POST /v1/skill/get returned HTTP 200 with an empty array. Consequently, PowerContextClient.get_skill and the Skill CLI cannot recover the exact entry/version supporting the published revision. Return the stored citations on this read path and update the stale Experience-only description in the SkillArtifact contract.

[hidb4ai]

please update & resolve conflicts

[hidb4ai]

Re-reviewed 0e601c29c2b2b8df085106beeec50f4e3da6aff9. The two previously reported issues are fixed: target-plus-independent-source proposals now reach approval, and exact Memory citations survive Skill reads through native APIs, HTTP, and the Python SDK.

The fresh real-model/OceanBase run completed generation, HTTP approval, replay, and restart readback for six operations. Topic Memory returned invalid_generation_output once; a separate real-model/OceanBase rerun completed the same flow. That failure remains unexplained, so this is not a clean first-pass result for all seven operations. Embeddings were disabled; installed hosts and SeekDB were not exercised.

One P2 remains in Memory-entry tag target evidence handling, detailed inline. Its database reproduction uses controlled generation output, separately from the real-model acceptance run.

[hidb4ai]

[P2] Mark Memory entry tag bases as target evidence

For a MemoryEntryTagTarget, basis_ref is None, so this passes no target to evidence resolution/selection even though basis_citation identifies it. The entry remains role="derived"; selecting only its target_evidence_id therefore counts as support and automatically adds its ancestor Source. I reproduced this on SQLite and real OceanBase with a controlled generator: no independent Sources, Artifacts, or other Memory citations were requested, the output selected only the target ID, yet the run returned proposed and approval persisted the tag. This contradicts the target-only needs_evidence rule enforced for Artifact tag targets. Preserve the exact Memory citation's target identity through resolution and selection, and cover the Memory-entry variant of the target-only regression.