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

id	ticket	title	created	tags
LSN-0012	packer-docs-import	Runtime ownership and Studio boundary legacy lesson	2026-03-26	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.