---
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`.