Ratify the registry freshness stamp — two editions, one file, stat-checked
2026-07-30 findings-resolution ruling (Redesign card 89862cef): the
mtime+size stamp the App Group implementation introduced (566deab) is
the designed mechanism, not an invention — checked before every registry
read and mutation, re-read on change, write on top of the other
edition's latest state. The microsecond check-to-write window stays
last-writer-wins, costing at most one convenience field. Deliberately no
NSFileCoordinator and no per-record split. Code already conforms.
Claude-Session: https://claude.ai/code/session_01CqjXB7ASoWtbyoGod68k97
This commit is contained in:
@@ -17,7 +17,7 @@ Separate Mac App Store apps — real Xcode targets, not an IAP unlock. Both edit
|
||||
**Both editions installed** (ruled 2026-07-29) — a supported steady state, not a transition to hurry past:
|
||||
|
||||
- **Pro claims the `.kanban` default on first launch, once.** The purchase is the consent — `.kanban` is the family's own exported UTI, not a shared public type, so the premium edition claiming its own documents is legitimate, and never asking would make the upgrade feel broken (boards keep opening in base). The claim is one-time: a user who later reassigns the default back to base in Finder is respected — Pro never re-asserts. Base never claims and never asks; until Pro's claim, LaunchServices' own resolution stands.
|
||||
- **The same board open in both apps at once is fine — it is the designed foreign-writer story, not a new hazard.** Base has no git (the inert-`.git` posture above): it never commits and never touches the repo, so there is no committer contention — base writing into a Pro-open board is exactly an agent writing from a terminal, which Pro's machinery (index.lock retry, flush-before-overwrite, abort-own-leftovers, "both versions exist as commits" — 06/07) was designed for; base sees Pro's writes as ordinary foreign reloads. No board-level lock — 02's files-first rule is absolute (no sidecar files), and no gate: "Open with…" into the second edition just works. Two conveniences ride the shared registry: **open-now flags are per-edition** (like the grant slots — an edition restores only the boards *it* had open), and the board popover carries a contextual awareness line ("Also open in Lanework Pro") read from the other edition's flag, pid-liveness-checked so crash residue never lies — a line, never a gate.
|
||||
- **The same board open in both apps at once is fine — it is the designed foreign-writer story, not a new hazard.** Base has no git (the inert-`.git` posture above): it never commits and never touches the repo, so there is no committer contention — base writing into a Pro-open board is exactly an agent writing from a terminal, which Pro's machinery (index.lock retry, flush-before-overwrite, abort-own-leftovers, "both versions exist as commits" — 06/07) was designed for; base sees Pro's writes as ordinary foreign reloads. No board-level lock — 02's files-first rule is absolute (no sidecar files), and no gate: "Open with…" into the second edition just works. Two conveniences ride the shared registry (concurrent writes reconciled by the freshness stamp — 02 ▸ Per-board app state): **open-now flags are per-edition** (like the grant slots — an edition restores only the boards *it* had open), and the board popover carries a contextual awareness line ("Also open in Lanework Pro") read from the other edition's flag, pid-liveness-checked so crash residue never lies — a line, never a gate.
|
||||
- **The clipboard staging store homes in the group container** beside the registry, so ⌘C in one edition pastes **full-fidelity** in the other — snapshot, attachments and all (04-interactions.md's staging lifecycle unchanged; both editions' launch/copy sweeps compute the same answer from the same pasteboard). A genuinely missing snapshot **refuses the paste loudly** (04-interactions.md's refuse-don't-degrade ruling, 2026-07-29) — with the shared store, no longer a structural cross-edition outcome.
|
||||
|
||||
## The provider seam
|
||||
|
||||
Reference in New Issue
Block a user