Add a composition conflict ledger and explicit PM4 reconciliation receipts

[jacksenpierce]

Status

Longer-term design investigation, not a commitment to a multi-parent merge model.

Problem to investigate

Parallel descendants can create same-pointer/different-meaning collisions, reuse graph membership ordinals, diverge in change-set receipts or resolutions, and inherit a runtime-oriented workstream identifier that is not a durable task or agent identity. Current snapshots have one parent, so a deliberate reconciliation cannot be represented as a true two-parent snapshot.

Desired exploration

Define a reconciliation record that can cite the chosen authority, external descendant, verified common base, considered conflicts, decisions, and omitted operations. Add diagnostics for pointer collisions, ordinal collisions, change-set divergence, and workstream/continuation scope.

Non-goals

No automatic merge, no deletion of conflicting history, and no pointer-renaming scheme should be assumed by this issue.

Related to #22.

[jacksenpierce]

Post-PM4 triage: multi-parent composition and alias/revision conflict inventories are delivered. Narrowing this issue to the missing decision artifact: a durable reconciliation receipt citing source workspaces, common base or absence thereof, conflicts considered, choices made, omissions, resulting head, and unresolved alternatives. No automatic semantic merge.

[jacksenpierce]

New unverified field evidence from YHX4's first reported divergent native PM4 composition: https://github.com/jacksenpierce/parmesan/blob/main/maintenance/incidents/2026-08-23-yhx4-first-divergent-pm4-composition.md

The report says composition itself behaved correctly: two divergent same-corpus descendants became a lawful multi-parent head; branch-local objects, revisions, replicas, aliases, memberships, operations, and ancestry remained present; validation passed; and ten meaningful alias collisions remained unresolved rather than being silently rewritten. Reported examples include CWV40–CWV43, CWA26, and SNT025, each reused lawfully for different branch-local meanings.

This sharpens the remaining deliverable. PM4 already inventories alias and revision-frontier conflicts. The missing layer is a durable composition conflict ledger plus reconciliation receipts that record:

• conflicting alias text and object UUIDs;
• source replicas, parent snapshots, local titles/descriptions, and membership contexts;
• status such as unresolved, same-meaning duplicate, lawful homonym, near-duplicate/bridge required, deprecated local alias, post-composition display rename, or promoted global alias;
• evidence, decision authority, bridge/successor objects, omissions, resulting head, and unresolved alternatives.

Unresolved collisions must remain lawful and inspectable. Resolution must not rewrite ancestral aliases or choose a branch merely because it has a higher sequence. This incident is unavailable for independent verification, so its counts and examples are evidence prompts rather than acceptance facts. Related scoped-read requirement is tracked separately.

[jacksenpierce]

Maintainer design note added to #44: investigate a first-class workspace-root node as the default context for local aliases and node readings. On composition, collisions could remain lawful by qualifying each alias through its parent workspace root rather than renaming ancestral assertions. If adopted, the conflict ledger here should record those workspace-qualified candidates and any later promotion to a composition-wide alias. Homologous/shared structure remains an explicit open question rather than grounds for automatic collapse.