architecture: retarget calendar projection authority from Naruon to CalendarWeave

[seonghobae]

Why this follow-up exists

Merged PR #355 correctly removed direct pseudo-CalDAV access from LineageWeave, but its compatibility contract treats Naruon as the calendar-provider authority and publishes application/vnd.contextualwisdomlab.naruon-calendar.v1+json.

CalendarWeave PR #1 now defines the organization target Context Map: CalendarWeave is the future authoritative generic calendar-resource/iCalendar/CalDAV/provider-sync bounded context; Naruon retains workspace commitment/conflict policy and cross-context scheduling decisions.

This issue does not invalidate #355. #355 remains a valid compatibility step that prevented LineageWeave from owning provider credentials, CalDAV state or writeback. The follow-up prevents that temporary Naruon projection from becoming the permanent calendar source of truth.

Target authority boundary

LineageWeave owns

• post-grounded commitments and issue/todo identity;
• lineage/ontology/provenance links and authorization;
• the combined buyer-facing calendar/evidence presentation;
• immutable observation evidence necessary to explain what was shown.

CalendarWeave owns after its production contract is released

• authoritative generic calendar event/occurrence references and revisions;
• iCalendar/CalDAV/provider calendar semantics;
• recurrence/timezone/provider mapping and sync evidence;
• calendar-resource authorization/audit receipts and read projections.

Naruon owns

• commitment meaning and confirmed/tentative/desired policy;
• conflict/resolution recommendations and private-context bridge;
• approval/correction workflow and business evidence that affects scheduling.

LineageWeave may later consume both CalendarWeave calendar observations and Naruon scheduling-decision evidence as separate typed sources. It must not collapse the two authorities into one DTO.

Migration rule

Do not rewrite or delete the merged #355 contract until CalendarWeave publishes a released, versioned read projection and immutable conformance fixtures.

1. Characterize the current naruon-calendar.v1 parser/client behavior and buyer UI.
2. CalendarWeave issue feat: Phase 1 product schema (3NF PostgreSQL, real DB tests) #2 must first deliver a real versioned calendar resource contract.
3. Introduce a new CalendarWeave consumer adapter/ACL in LineageWeave; do not rename the old media type in place.
4. If Naruon decision/conflict evidence is also needed, consume it through a separate Naruon scheduling-decision contract rather than using Naruon as generic calendar authority.
5. Prove parity for opaque identities, revisions, intervals, timezone/all-day, disclosure, observation provenance, bounds, timeout/degraded behavior and tenant authorization.
6. Only after parity retire the compatibility Naruon calendar projection path through an explicit version/deprecation window.
7. Add architecture-fitness tests forbidding direct CalDAV/provider access and forbidding Naruon provider DTOs from becoming the permanent LineageWeave calendar domain model.

DDD consequence

The LineageWeave Calendar surface is a composition/read-model boundary, not a Calendar aggregate. External calendar observations remain external evidence. LineageWeave commitments remain LineageWeave facts. CalendarWeave resources remain CalendarWeave facts. Naruon commitment decisions remain Naruon facts.

Done

Close only when the buyer-facing calendar composition uses the correct versioned authorities without direct provider credentials or foreign database access, the compatibility path is either deliberately retained or safely retired, and exact-head tests/docs/coverage/security/review evidence pass.

[seonghobae]

2026-09-01 fresh owner-contract read: CalendarWeave is advancing, but the migration precondition is still not met. CalendarWeave#1 remains Draft (ownership/context map only); #3 remains Draft on #1 and explicitly lacks a durable store/CalDAV service/release; #4 remains Draft on #3 with PostgreSQL durability but no authenticated service/CalDAV/provider parity/release; #5 remains Draft on #4 and explicitly leaves VTIMEZONE, recurrence, CalDAV, provider adapters, service authentication, and consumer migration unavailable. Therefore LineageWeave must not retarget the merged naruon-calendar.v1 compatibility projection yet.

This does not block the bounded #904 cleanup of the unused direct pseudo-CalDAV /events adapter/configuration: that PR preserves the Naruon compatibility consumer and removes an authority LineageWeave should not own. CalendarWeave migration remains gated on a released/versioned read projection plus immutable conformance fixtures and parity evidence as described above.