[task] Version or migrate runtime OPENBOT.md seed

[lukemaj]

State: blocked by #85.

Parent: [spec] OpenBot v1.

Required by: [spec] V1 Isolated config and Screen-first Bot environment.

Problem

OPENBOT.md is product-locked runtime guidance, but it is not a tracked repo file. The repo source is the OPENBOT_MD string in daemon/src/harness-home.ts; deployment/startup seeds the runtime file at $OPENBOT_HOME/harness/shared/OPENBOT.md through ensureHarnessHome(...).

Today that seed uses writeIfMissing(...). Existing installs keep whatever OPENBOT.md was first created with. Restarting or deploying newer code does not update it.

Observed on this machine:

• Repo checkout: /Users/lukaszmaj/Documents/ChatGPT/openbot
• No tracked repo OPENBOT.md exists.
• Runtime file exists at /Users/lukaszmaj/.openbot/harness/shared/OPENBOT.md.
• Current source constant is in daemon/src/harness-home.ts.
• Runtime file had extra Isolated command guidance about running process exec through docker exec into Screen, while the current source constant did not.

That means the product-locked instruction file can drift from the code that is supposedly shipping it.

Solution

Add an explicit update/migration path for $OPENBOT_HOME/harness/shared/OPENBOT.md.

Keep user-editable files protected:

• Users edit Workspace/AGENTS.md for All Bots.
• Users edit Workspace/bots/<id>/AGENTS.md for This Bot.
• Users do not edit harness/shared/OPENBOT.md.

Reasonable implementation shape:

• Treat runtime OPENBOT.md as product-owned, not user-owned.
• Store a version/hash/sentinel for the product seed, or compare against known prior product seeds.
• On startup, update the file when it is an old product seed.
• If the file has unknown local edits, do not silently overwrite; either preserve with a backup or surface a clear warning.
• Keep vendor symlinks pointing at ../shared/OPENBOT.md.

Done When

1. A fresh Home still creates $OPENBOT_HOME/harness/shared/OPENBOT.md from the current product seed.
2. An existing Home with a known old product seed is migrated to the current product seed on startup.
3. An existing Home with unknown/manual edits is not silently destroyed.
4. Codex/Grok/Kimi vendor homes still link AGENTS.md to ../shared/OPENBOT.md; Claude still links CLAUDE.md to it.
5. A targeted test covers fresh seed, known-seed migration, and unknown-edit preservation/warning.
6. The issue body or implementation notes make clear that deploy/restart is not enough unless this migration runs.
7. The migrated product seed contains the finalized common and Isolated-config environment brief from the required [spec] V1 Isolated config and Screen-first Bot environment #81 implementation ticket, without the superseded Workspace-jail or active Host-grant authorization claims.

Notes

This ticket is about product runtime file lifecycle, not changing All Bots or This Bot editor behavior.

Related context: Isolated Harness Home (#58), PinchTab Talk MCP (#59), Isolated exec (MCP) (#69).

Blocked by

• [task] Give new Sessions the mode-aware OpenBot environment brief

[lukemaj]

Runtime OPENBOT.md migration must be implemented after #85 on the combined v1 train from #116. Migrating only the current isolated train would seed the old Workspace-jail/Host-grant contract into a product that has not yet incorporated the final Messenger/config surfaces.

[lukemaj]

Baseline correction from the exact combined-train audit:

The current 47923fd implementation no longer uses the historical writeIfMissing behavior described in this issue. Startup unconditionally calls writeProductFile(..., OPENBOT_MD), the helper directly overwrites the file, and the current test expects arbitrary stale instructions to be replaced.

That behavior updates stale product text, but it still does not satisfy #70 because unknown/manual edits are silently destroyed. It also writes the current superseded seed. #85 must first freeze the correct mode-aware environment brief, after which #70 can implement explicit missing, known-old, current, and unknown-edited classification with atomic migration and preserved vendor symlinks.

The issue remains correctly blocked by #85. No code worker should start from the current unconditional-overwrite baseline.