Repository navigation
Conversation
DREAMING.md was declared as the Dreaming prompt file, but nothing read it. resolveSpecialIdentityFiles had no callers, and Dreaming builds its prompt in platform/daemon/src/pipeline/dreaming.ts. Setup still wrote the file into every managed workspace, and its guidance contradicts the current Dreaming contract, so edits to it silently did nothing. Remove the dreaming identity file, the DREAMING.md preset entries, the template, resolveSpecialIdentityFiles and the identity.special parsing that only it used. HEARTBEAT.md and BOOTSTRAP.md stay as OpenClaw special-session files. Existing workspaces keep working: a DREAMING.md on disk is ignored as before. A kind: dreaming entry in agent.yaml is ignored, reported by signet doctor as an info finding, and dropped when dashboard onboarding re-saves identity. Without that filter onboarding would have promoted DREAMING.md into startup.load. Headless setup plans that still request a dreaming special file now fail validation explicitly. Refs #2038 Assisted-by: Claude-Code:claude-opus-5-5
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (20)
💤 Files with no reviewable changes (2)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe changes remove ChangesDREAMING.md identity retirement
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Refactor · Severity of issue fixed: Low Suggested reviewers: Merge Risk: ⚪ Minimal · up to The retirement appears ready to merge after normal checks; no actionable issue is established by the supplied evidence. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 12 files. (6 skipped: 6 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A headless setup plan that still lists a kind: dreaming special file failed with zod's generic "expected one of heartbeat|bootstrap", which does not say the file was retired or what to do. Name DREAMING.md as retired and tell the user to remove the entry. Other invalid kinds keep the default message. Refs #2038 Assisted-by: Claude-Code:claude-opus-5-5
Summary
DREAMING.mdwas declared as the Dreaming prompt file, but nothing read it.resolveSpecialIdentityFilesinplatform/core/src/identity.tshad no callers in the daemon, connectors, or surfaces, and Dreaming builds its prompt entirely inplatform/daemon/src/pipeline/dreaming.ts(DREAMING_AGENT_PROMPT). Setup still wroteDREAMING.mdinto every managed workspace. Its guidance contradicts the current Dreaming contract, and edits to it had no effect.This PR removes the file from the identity spec, the presets, setup, the dashboard, and the docs. Workspaces that still have it keep working.
Fixes #2038
Changes
platform/core/src/identity-spec.ts: removed thedreamingentry fromIDENTITY_FILESand theDREAMING.mdentries from every preset'sspeciallist.minimal,hermes, andcustomnow havespecial: [].IdentitySessionKindis now"heartbeat" | "bootstrap". AddedisRetiredIdentitySpecialEntry, a pure predicate forkind: dreamingentries.platform/core/src/identity.ts,index.ts: removedresolveSpecialIdentityFilesand its export, plusreadSpecialIdentityEntry/readSpecialIdentityEntryList, which only it used. AddedlistRetiredIdentityEntries(agentsDir). It is used only for diagnostics and never resolves or reads the files.surfaces/cli/templates/DREAMING.md.template: deleted.setup-migrate.tsno longer writes the file or theidentity.specialentry. Fresh setup gets this automatically from the presets.surfaces/cli/src/features/setup-plan.ts: the plan schema no longer acceptskind: "dreaming", and rejects it with a message that namesDREAMING.mdas retired.surfaces/cli/src/features/health.ts:signet doctoradds aninfofinding (retired_identity_file) whenagent.yamlstill has akind: dreamingentry underidentity.special. Doctor status is unchanged.surfaces/dashboard/src/components/onboarding/{page,identity-step}.tsx: removed the template import, and onboarding now filters retired entries when it loads and saves identity config. Without the filter, re-saving identity on an existing workspace would have movedDREAMING.mdintostartup.loadwith nokind, so it would have been loaded into ordinary startup context (verified: the new test fails without this filter).web/docs/.../getting-started/setup.mdx,web/docs/.../configuration/workspace-identity.md,skills/onboarding/SKILL.md,docs/specs/approved/dreaming-memory-consolidation.md, the success criterion indocs/specs/dependencies.yaml, and theweb/marketinghome mockup.Decisions
The issue left two choices open:
identity.specialdreaming entries inagent.yamlare ignored with a diagnostic, not failed. Every managed workspace created before this change has that entry. Failing would break all of them, which contradicts the acceptance criterion that existing workspaces behave the same. No code reads the entry.signet doctorreports it, and dashboard onboarding drops it the next time identity is saved. Signet does not rewriteagent.yamlon its own, and it never deletesDREAMING.mdfrom disk.signet setup --file) that ask for adreamingspecial file fail validation explicitly. A plan is new, explicit input asking setup to create a retired file. PerAGENTS.md, retired inputs fail explicitly. The error namesspecialIdentityFiles.N.kind, saysDREAMING.mdis retired, and tells the user to remove the entry.I kept
IdentitySpecialFileEntryand thespecialpreset field (narrowed rather than deleted). OpenClaw'sHEARTBEAT.mdandBOOTSTRAP.mdstill go through them for setup andagent.yaml. Nothing in Signet reads those two files either; OpenClaw reads them natively. Whether that mechanism should go too is outside this issue.Type
feat— new user-facing feature (bumps minor)fix— bug fixrefactor— restructure without behavior changechore— build, deps, config, docsperf— performance improvementtest— test coveragePackages affected
@signet/core@signet/daemon@signet/cli/ dashboard@signet/sdk@signet/connector-*@signet/webpredictorskills/onboarding,docs/specsScreenshots
No visual change. The dashboard edit only changes which identity config entries onboarding keeps.
DREAMING.mdwas already hidden from the onboarding file picker throughMANAGED_FILES.Testing
bun testpassesbun run typecheckpassesbun run lintpassesWhat I ran:
bun test platform/core/src/__tests__/identity.test.ts: 38 pass. Covers: no preset or identity file declaresDREAMING.md; an existing workspace with the retired entry and file still loads onlyAGENTS.md, andloadIdentityFilesSyncno longer picks the file up;listRetiredIdentityEntriesreports dreaming entries but not heartbeat or bootstrap ones.bun test surfaces/cli/src/features/{health,setup-plan,setup}.test.ts: 159 pass. Covers: the minimal, custom, and openclaw presets no longer writeDREAMING.mdor the yaml entry, even when an old template is still present; a plan with a dreaming special file is rejected with the retired-file message; the doctor finding appears for a dreaming entry and not for a heartbeat entry.bun test surfaces/dashboard/src/components/onboarding/page.test.tsx: passes. The new case re-saves identity on a workspace that has the retired entry. It confirmsagent.yamlno longer mentionsDREAMING.mdand that the file's contents are untouched. This case fails on the oldpage.tsx, whereDREAMING.mdends up instartup.load.tsc --noEmitfor@signet/core,signet-dashboard, and@signet/daemon;bunx biome checkon the changed files;bun run comments:check.bun scripts/spec-deps-check.tsfails, but with the samekimi-harness-provider-supporterror that main already has. Nothing in it comes from this change.Live verification (PR daemon on an isolated port, HOME, and workspace; main's build on a second port for comparison):
signet setup --non-interactivefrom the PR CLI (minimalandopenclawpresets) writes noDREAMING.mdand nokind: dreamingentry.minimalgetsspecial: [].openclawkeepsHEARTBEAT.mdandBOOTSTRAP.md.DREAMING.mdand thekind: dreamingentry, and added a marker string toDREAMING.md. The PR daemon booted clean on it:/healthwashealthy, and the only warning in the logs was the usual "Dashboard not found". PRsignet doctor --jsonreportsretired_identity_fileatinfoand listsretiredIdentityEntries: ["DREAMING.md"]. Status stayshealthywith exit code 0, the same as main's doctor on the same workspace, which doesn't report the finding.POST /api/hooks/session-startinjectsAGENTS.mdbut not theDREAMING.mdmarker.signet setup --filewith akind: "dreaming"special file fails with exit 1:specialIdentityFiles.0.kind: the dreaming special file (DREAMING.md) is retired; remove this entry. Dreaming builds its own prompt, and nothing is written. Main accepts the same plan and writesDREAMING.md. A plan with aheartbeatspecial file still applies on the PR.page.tsxagainst the running daemon (GET /api/config, thenPOST /api/configwith the stringifiedagent.yaml). With the filter, theminimalandcustompresets both drop the entry, leavingstartup.load: [AGENTS.md]andspecial: [].DREAMING.mdon disk is byte-identical, session-start doesn't inject it, and doctor no longer reports the finding. Without the filter, the PR presets moveDREAMING.mdintostartup.loadand session-start injects its marker, which is the regression the filter prevents. The daemons shut down cleanly.AI disclosure
Assisted-bytags in commits)Notes
The commit bodies say
Refs #2038. This PR fully covers the issue, henceFixes #2038above.Summary by CodeRabbit
DREAMING.mdor other identity files.DREAMING.md. Existing files are ignored, and onboarding removes retired Dreaming entries from configuration while preserving file contents.