Sharing data between original PAI and PAI opencode

[wojteksbt]

Hi! I have an existing PAI setup (danielmiessler/Personal_AI_Infrastructure) where all personal data and overrides live in a separate repo using the “move out, link back” symlink pattern (https://github.com/ecielam/pai-personal-data).

Now I want to add PAI-OpenCode (Steffen025/pai-opencode) in a way that:

• keeps a single “source of truth” personal-data repo (TELOS, identity, preferences, MEMORY, etc.)
• lets me run both setups side-by-side:
  • Claude Code PAI in ~/.claude (hooks-based)
  • PAI-OpenCode in .opencode (plugins-based)
• avoids collisions or semantic conflicts in shared directories (especially MEMORY/STATE and session artifacts)
• preserves the rule “never overwrite user customizations” across upgrades/updates of either system

Questions:

• Should WORK be shared or kept separate between Claude Code and OpenCode? Perhaps not?
• Are there known conflict points in MEMORY (e.g., STATE/, session transcripts) when both runtimes write to the same tree, and is there a recommended convention to prevent collisions?

[Steffen025]

Great question! This is a common scenario as PAI-OpenCode grows alongside the original PAI.

TL;DR Recommendation

Share static data, separate runtime state.

Directory	Share?	Why
USER/ (TELOS, Identity)	✅ Yes	Static personal data, no runtime conflicts
skills/PAI/USER/	✅ Yes	Skill customizations, rarely written
MEMORY/LEARNING/	⚠️ Careful	Append-only, but filename collisions possible
MEMORY/STATE/	❌ No	Active runtime state, write conflicts guaranteed
MEMORY/WORK/	❌ No	Session-specific, locks, active writes
MEMORY/SESSIONS/	❌ No	Platform-specific transcript formats

Architecture Suggestion

pai-personal-data/              # Your external repo
├── USER/                       # ✅ Shared identity
│   ├── TELOS/
│   ├── DAIDENTITY.md
│   └── ...
└── skills-user/                # ✅ Shared skill customizations
    └── PAI/USER/

~/.claude/                      # Claude Code PAI
├── USER -> ../pai-personal-data/USER
├── skills/PAI/USER -> ../pai-personal-data/skills-user/PAI/USER
└── MEMORY/                     # ❌ Keep separate
    ├── STATE/                  # Platform-specific
    ├── WORK/                   # Platform-specific
    └── LEARNING/               # Could share, but recommend separate

.opencode/                      # PAI-OpenCode
├── USER -> ../pai-personal-data/USER
├── skills/PAI/USER -> ../pai-personal-data/skills-user/PAI/USER
└── MEMORY/                     # ❌ Keep separate
    ├── STATE/
    ├── WORK/
    └── LEARNING/

Why Not Share WORK/?

Both systems use MEMORY/WORK/ for active session tracking:

1. current-work.json - Written on every prompt, tracks active work ID
2. Work directories - Created per session, contain locks
3. ISC.json - Captured during Algorithm execution

If both Claude Code and OpenCode write here simultaneously, you'll get:

• Race conditions on current-work.json
• Orphaned work directories
• Corrupted state

Why Not Share STATE/?

MEMORY/STATE/ contains runtime state that's fundamentally platform-specific:

• algorithm-state.json - Current Algorithm phase
• format-streak.json - Response format tracking
• tab-state.json (OpenCode only) - Terminal integration

These files are written during every interaction. Sharing them would cause constant conflicts.

Sharing LEARNING/ - Proceed with Caution

MEMORY/LEARNING/ is mostly append-only (ratings.jsonl, learnings). You could share it, but:

Risk: Both systems might create files with the same timestamp-based name if you work in both simultaneously.

Mitigation: If you want shared learnings, consider:

1. Running only one system at a time
2. Using a merge script instead of symlinks
3. Accepting occasional duplicate entries

The "Never Overwrite User Customizations" Rule

This rule applies to USER/ and skills/PAI/USER/ directories, which are explicitly gitignored in both systems. Upgrades never touch these.

For MEMORY/, the rule is different - these are runtime artifacts, not customizations. Both systems expect exclusive write access.

Practical Recommendation

1. Share: USER/, skills/PAI/USER/
2. Don't share: MEMORY/ (any of it)
3. Consider: A periodic sync script that merges LEARNING/ entries

This gives you unified identity and preferences while avoiding runtime conflicts.

---

Let me know if you'd like me to create a documentation page for this multi-installation pattern!