Implement fresh-session rebootstrap for topic-bound orchestrator prompts

[fujiwaranosai850]

From research #194

Overview

Implement a low-risk fix for stale orchestrator prompt reuse across /new on topic-bound sessions. The working diagnosis is that prompt precedence alone is not the primary bug. The likely failing layer is fresh-session lifecycle or bootstrap artifact reuse for the same topic-bound orchestrator session key. The implementation should ensure that a fresh /new rebuilds orchestrator bootstrap context from current disk state, resolves exactly one prompt source with winner-takes-all precedence, and never serves stale injected orchestrator.md material from a previous session state.

Use the prior #190 implementation lane as reference where helpful, especially for real chat/topic session-key targeting and project/topic-aware orchestrator prompt resolution, but validate against the current live failure shape before landing.

Implementation Checklist

Phase 1: Reproduce and instrument the real failure path (~1 day)

• Identify the actual /new lifecycle path used for orchestrator sessions and document whether it deletes/recreates the target session or only clears conversational history/state.
• Add temporary diagnostic logging around orchestrator bootstrap invocation to capture sessionKey, resolved project/topic scope, resolved source path, and a short content fingerprint or semantic marker.
• Add temporary diagnostics around bootstrap artifact handling to show whether orchestrator.md is rebuilt, replaced, or reused when /new targets the same topic-bound session key.
• Reproduce the operator’s marker sequence (wasps / fire hullcracker → ticks / fire stitcher → remove project prompt) and confirm exactly which layer goes stale.

Phase 2: Implement deterministic fresh-session bootstrap behavior (~1.5 days)

• Restore or re-apply dedicated orchestrator bootstrap support so live chat-backed orchestrator sessions, including Telegram topic session shapes, are correctly targeted instead of relying on legacy agent:<id>:main assumptions.
• Ensure orchestrator prompt resolution is strict winner-takes-all across devclaw/projects/<project>/prompts/orchestrator.md, devclaw/prompts/orchestrator.md, and package default, with no layering or merging.
• Update the fresh-session /new path so a new session on an existing topic-bound logical key discards old bootstrap material before first turn, either by deleting/recreating the session object or by an explicit full rebootstrap step that replaces prior synthetic artifacts atomically.
• Ensure that when orchestrator bootstrap runs, any existing injected orchestrator.md entry is overwritten from current disk resolution, and stale content cannot survive if the previously winning file is edited or removed.

Phase 3: Regression tests and cleanup (~1 day)

• Add unit/integration tests for real orchestrator session-key targeting and project/topic-aware orchestrator prompt resolution in lib/dispatch/bootstrap-hook.test.ts and/or lib/services/bootstrap.e2e.test.ts.
• Add a higher-fidelity regression test or harness scenario that models repeated fresh-session boots on the same topic-bound logical session key while prompt files change between runs.
• Cover these semantic transitions explicitly: workspace marker wins, project marker wins, project file removed so workspace wins again, project file changed so new project marker wins.
• Add negative assertions that prior markers do not survive after /new.
• Remove or downgrade temporary diagnostics after tests and live verification are in place, keeping only durable trace logs that are genuinely useful in production.

Dependencies & Blockers

• The exact /new lifecycle may live partly outside the currently inspected DevClaw plugin code, so the developer may need to touch the gateway/session lifecycle layer in addition to lib/dispatch/bootstrap-hook.ts.
• The reverted commit history around b187665b4d563c040cbf685622b4d10836c68a1d should be used carefully as reference, but the implementation must be validated against the stronger stale-session evidence, not just filename presence.
• If the real stale behavior is confirmed in OpenClaw core rather than DevClaw prompt resolution, the fix should be made at that lifecycle boundary instead of papering over it in the loader.

Estimated Total: 3-4 days

[fujiwaranosai850]

🎛️ ORCHESTRATOR: Operator evidence handoff for implementation.

Please use the following as the primary real-world repro, not just the abstract stale-bootstrap hypothesis.

Core operator finding

A fresh /new on the same topic-bound orchestrator session key can still surface older semantic prompt content after prompt files on disk were changed.

The important repeated session identity in testing was:

• agent:devclaw:telegram:group:-1003746138337:topic:1

Semantic markers used in live testing

Workspace-wide orchestrator prompt marker:

• wasps / fire hullcracker

First Light project-specific orchestrator prompt marker:

• ticks / fire stitcher

These markers were chosen specifically so we could tell which source actually won in live context.

Critical real-world observation

The strongest operator claim is:

• at the time of a fresh /new, the First Light project orchestrator prompt did not exist on disk
• yet the new context still answered with the project-specific marker:
  • ticks
  • fire stitcher

If that observation is accurate, current-disk prompt precedence alone cannot explain the result.

Additional important context

• The visible path shown in model context was often /home/sai/.openclaw/workspace/orchestrator.md
• that path appears to be a synthetic injected artifact path, not a trustworthy source-path indicator
• package default orchestrator prompt does not contain the ticks / fire stitcher marker

Operator frustration / testing gap

The operator's main complaint is that prior debugging drifted too much into theory about what should happen, instead of re-verifying the actual filesystem state and live /new behavior every time.

Please keep the implementation grounded in the live repro:

1. same topic-bound session key reused across /new
2. prompt files changed between tests
3. semantic marker from an earlier file state still appears after a fresh /new

What implementation should preserve

• winner-takes-all prompt source resolution
• exactly one injected orchestrator.md
• no project/workspace layering
• fresh /new must rebuild from current disk state, not reuse stale prompt material

Please use this operator evidence directly when implementing and when deciding what runtime instrumentation / regression coverage is necessary.

[fujiwaranosai850]

🔧 DEVELOPER: Refining hold reason

DevClaw is moving this issue from Doing to Refining because work cannot continue yet.

Why this is on hold

• Implementation is complete and a PR is open at fix: rebootstrap topic-bound orchestrator prompts #196, but work_finish(done) is blocked by branch detection in the tool, which is still looking for PRs from devclaw-local-current instead of issue/195-fresh-session-rebootstrap.

Transition details

• from: Doing
• to: Refining
• category: work_finish_blocked
• source: worker

Context

• role: developer
• result: blocked

Please review this hold reason and update the issue before re-queueing it.