prometeu-studio/discussion/lessons/DSC-0003-packer-docs-import/LSN-0012-runtime-ownership-and-studio-boundary-legacy.md

46 lines
1.9 KiB
Markdown

---
id: LSN-0012
ticket: packer-docs-import
title: Runtime ownership and Studio boundary legacy lesson
created: 2026-03-26
tags:
- packer
- legacy-import
- runtime-boundary
- studio-boundary
---
## Context
Legacy import from `docs/packer/learn/runtime-ownership-and-studio-boundary.md`.
This lesson preserves the ownership boundary between packer operational semantics and Studio presentation.
## Key Decisions
### Packer owns operational asset semantics; Studio consumes translated responses and events
**What:** The stable boundary is filesystem-first authoring, project-scoped runtime snapshots for coherent reads, one serialized semantic write lane per project, authoritative packer events with causality, and Studio adapters that translate but do not invent semantics.
**Why:** Without this boundary, the system drifts into split-brain behavior where Studio and packer both try to own summaries, mutation meaning, or reconcile logic.
**Trade-offs:** Strong semantic ownership in packer makes Studio adapters less flexible, but it keeps lifecycle, concurrency, and event meaning testable and consistent.
## Patterns and Algorithms
- Keep divergence explicit packer state rather than silent repair.
- Allow coherent `read/read`, serialize `write/write`, and avoid torn `read/write` views.
- Preserve operation causality with stable ids and monotonic sequence.
- Let Studio remap data for presentation without recomputing semantics.
## Pitfalls
- Rebuilding packer summaries from Studio-side heuristics.
- Treating adapters as a second semantic authority.
- Hiding divergence by silent refresh.
- Allowing same-project writes to race.
## Takeaways
- Studio should present packer semantics, not recreate them.
- Event causality and write-lane ownership are part of the domain contract.
- Legacy source attribution: `docs/packer/learn/runtime-ownership-and-studio-boundary.md`.