beo-dream

Purpose

Consolidate cross-feature learning.

Primary owned decision

Decide whether accepted feature evidence supports a shared learning update or an explicit non-promotion.

Ownership predicate

• At least two accepted features support the same shared learning candidate.
• The user explicitly requests corpus-level consolidation. "User explicitly requests corpus-level consolidation" means a direct named request in the current task or a fresh handoff with explicit corpus consolidation authorization; it does not include inferred intent from go-mode or approval context.
• Existing shared learning guidance needs consolidation from accepted feature records only when the consolidation threshold is met.
• A single-feature case is in scope only when the user explicitly asks for corpus-level analysis.

Writable surfaces

• Shared learning guidance surfaces explicitly approved by the user. When approval grants shared-guidance mutation, write to the user-confirmed target file path only. Do not infer a canonical shared guidance location; if no target path has been confirmed, surface the path choice to the user before writing.
• Consolidation records described by canonical learning doctrine.
• Shared state/handoff fields allowed by beo-reference → skill-contract-common.md.

Canonical: beo-reference → learning.md Locally enforced as:

• Use canonical consolidation thresholds.
• Do not promote one feature without an explicit corpus-level request.
• Do not write feature-level learning; use beo-compound for that.

Hard stops

• Apply the canonical go-mode handoff gate from beo-reference → go-mode.md; if persistence evidence is absent or false, clear go-mode before normal gates.
• Do not mutate shared guidance without threshold or explicit corpus-request evidence.
• Do not treat go-mode authorization, implicit user intent, or conversational phrasing as an explicit corpus-level consolidation request. An explicit request requires either a direct user instruction naming corpus consolidation in the current task, or a fresh handoff with intended_resume_owner=beo-dream and a recorded corpus_consolidation_request=true field. When the request is ambiguous, route to user before proceeding.
• Do not implement product changes or reopen review.
• Do not infer shared doctrine from isolated evidence.
• Do not write feature-level learning records; that is beo-compound's surface (beo-compound owns single-feature, feature-local records; beo-dream owns multi-feature cross-feature shared guidance). Route single-feature outcomes to beo-compound before consolidation.
• Before writing to any shared learning guidance surface, record the user_approval_ref in the consolidation card and in STATE.json.evidence. If no current-task or fresh-handoff authorization exists, emit needs-user and route to user before writing. Authorization from a prior session is not valid unless it is recorded in a fresh handoff with corpus_consolidation_request=true and the target file path explicitly named.

Corpus consolidation card

Candidate:
Source features checked:
Threshold evidence:
Conflict check:
User approval ref: <direct instruction in current task | handoff field corpus_consolidation_request=true | none>
Target file confirmed by user: <path or pending>
Decision: consolidation-candidate | no-promotion | needs-user
Authority note: display-only; canonical authority remains in the referenced state/artifact surface.

Allowed next owners

• user
• done

References

• beo-reference → operator-card.md — read when formatting operator-facing consolidation results.
• beo-reference → learning.md — read when applying consolidation thresholds and provenance rules.
• beo-reference → pipeline.md — read when choosing legal closure handoffs.
• beo-reference → state.md — read when updating state or handoff surfaces.