You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@causeway.apache.org by da...@apache.org on 2026/09/22 20:51:21 UTC
(causeway) 07/07: CAUSEWAY-4058: prunes archived OpenSpec history
This is an automated email from the ASF dual-hosted git repository.
danhaywood pushed a commit to branch CAUSEWAY-4058
in repository https://gitbox.apache.org/repos/asf/causeway.git
commit 473d2c218c4caade58b983d73bbbf452270b7075
Author: Dan Haywood <da...@haywood-associates.co.uk>
AuthorDate: Tue Sep 22 19:43:18 2026 +0100
CAUSEWAY-4058: prunes archived OpenSpec history
---
.../.openspec.yaml | 2 -
.../design.md | 56 ---
.../proposal.md | 25 -
.../spec.md | 38 --
.../tasks.md | 20 -
.../.openspec.yaml | 2 -
.../design.md | 48 --
.../proposal.md | 27 -
.../specs/command-replay-result-mapping/spec.md | 18 -
.../spec.md | 44 --
.../tasks.md | 24 -
.../.openspec.yaml | 2 -
.../design.md | 66 ---
.../proposal.md | 34 --
.../specs/command-replay-result-mapping/spec.md | 25 -
.../spec.md | 28 --
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../design.md | 50 --
.../proposal.md | 24 -
.../specs/command-export-yaml-result/spec.md | 25 -
.../tasks.md | 24 -
.../.openspec.yaml | 2 -
.../design.md | 50 --
.../proposal.md | 28 --
.../specs/command-replay-result-mapping/spec.md | 39 --
.../tasks.md | 21 -
.../.openspec.yaml | 2 -
.../design.md | 70 ---
.../proposal.md | 32 --
.../spec.md | 36 --
.../spec.md | 98 ----
.../tasks.md | 45 --
.../.openspec.yaml | 2 -
.../design.md | 56 ---
.../proposal.md | 29 --
.../specs/command-replay-result-mapping/spec.md | 91 ----
.../tasks.md | 26 -
.../.openspec.yaml | 2 -
.../design.md | 46 --
.../proposal.md | 28 --
.../specs/command-export-yaml-result/spec.md | 33 --
.../tasks.md | 22 -
.../.openspec.yaml | 2 -
.../design.md | 50 --
.../proposal.md | 27 -
.../specs/command-replay-result-mapping/spec.md | 38 --
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 81 ---
.../proposal.md | 28 --
.../specs/command-export-yaml-result/spec.md | 19 -
.../specs/command-replay-result-mapping/spec.md | 33 --
.../specs/safe-action-command-publishing/spec.md | 54 --
.../tasks.md | 44 --
.../.openspec.yaml | 2 -
.../design.md | 48 --
.../proposal.md | 27 -
.../parented-collection-selector-actions/spec.md | 48 --
.../tasks.md | 17 -
.../.openspec.yaml | 2 -
.../design.md | 46 --
.../proposal.md | 29 --
.../specs/command-export-yaml-result/spec.md | 28 --
.../specs/safe-action-command-publishing/spec.md | 35 --
.../tasks.md | 22 -
.../.openspec.yaml | 2 -
.../design.md | 48 --
.../proposal.md | 26 -
.../parented-collection-selector-actions/spec.md | 46 --
.../tasks.md | 12 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 26 -
.../parented-collection-selector-actions/spec.md | 36 --
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 33 --
.../parented-collection-selector-actions/spec.md | 49 --
.../specs/safe-action-command-publishing/spec.md | 51 --
.../tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 81 ---
.../proposal.md | 27 -
.../parented-collection-selector-actions/spec.md | 92 ----
.../specs/safe-action-command-publishing/spec.md | 19 -
.../tasks.md | 32 --
.../.openspec.yaml | 2 -
.../design.md | 53 --
.../proposal.md | 28 --
.../parented-collection-selector-actions/spec.md | 42 --
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 49 --
.../proposal.md | 25 -
.../parented-collection-selector-actions/spec.md | 178 -------
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 45 --
.../proposal.md | 25 -
.../parented-collection-selector-actions/spec.md | 64 ---
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 56 ---
.../proposal.md | 27 -
.../parented-collection-selector-actions/spec.md | 59 ---
.../tasks.md | 18 -
.../.openspec.yaml | 2 -
.../design.md | 42 --
.../proposal.md | 25 -
.../specs/command-export-yaml-result/spec.md | 84 ----
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 43 --
.../proposal.md | 24 -
.../parented-collection-selector-actions/spec.md | 51 --
.../tasks.md | 14 -
.../.openspec.yaml | 2 -
.../design.md | 64 ---
.../proposal.md | 31 --
.../parented-collection-selector-actions/spec.md | 145 ------
.../tasks.md | 26 -
.../.openspec.yaml | 2 -
.../design.md | 42 --
.../proposal.md | 25 -
.../spec.md | 21 -
.../tasks.md | 20 -
.../.openspec.yaml | 2 -
.../design.md | 48 --
.../proposal.md | 26 -
.../spec.md | 73 ---
.../2026-06-07-add-replay-mapping-finders/tasks.md | 28 --
.../.openspec.yaml | 2 -
.../design.md | 39 --
.../proposal.md | 31 --
.../specs/replayable-command-remappings/spec.md | 71 ---
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 33 --
.../proposal.md | 27 -
.../specs/replayable-command-remappings/spec.md | 85 ----
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 43 --
.../proposal.md | 28 --
.../parented-collection-selector-actions/spec.md | 65 ---
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 44 --
.../proposal.md | 28 --
.../parented-collection-selector-actions/spec.md | 73 ---
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 43 --
.../proposal.md | 27 -
.../specs/command-replay-result-mapping/spec.md | 22 -
.../spec.md | 37 --
.../tasks.md | 32 --
.../.openspec.yaml | 2 -
.../design.md | 42 --
.../proposal.md | 28 --
.../parented-collection-selector-actions/spec.md | 25 -
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 42 --
.../proposal.md | 27 -
.../specs/replayable-command-actions/spec.md | 47 --
.../tasks.md | 22 -
.../.openspec.yaml | 2 -
.../design.md | 69 ---
.../proposal.md | 29 --
.../specs/command-recording-suppression/spec.md | 62 ---
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../2026-06-07-record-all-replay-results/design.md | 51 --
.../proposal.md | 29 --
.../specs/command-replay-result-mapping/spec.md | 79 ---
.../spec.md | 58 ---
.../spec.md | 75 ---
.../2026-06-07-record-all-replay-results/tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 37 --
.../proposal.md | 36 --
.../specs/replayable-command-remappings/spec.md | 63 ---
.../tasks.md | 21 -
.../.openspec.yaml | 2 -
.../design.md | 49 --
.../proposal.md | 27 -
.../parented-collection-selector-actions/spec.md | 92 ----
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 32 --
.../proposal.md | 29 --
.../specs/replayable-command-remappings/spec.md | 31 --
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 35 --
.../proposal.md | 29 --
.../specs/replayable-command-remappings/spec.md | 137 -----
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 68 ---
.../proposal.md | 29 --
.../parented-collection-selector-actions/spec.md | 94 ----
.../tasks.md | 19 -
.../.openspec.yaml | 2 -
.../design.md | 48 --
.../proposal.md | 29 --
.../specs/replayable-command-remappings/spec.md | 24 -
.../tasks.md | 16 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 30 --
.../specs/replayable-command-remappings/spec.md | 36 --
.../tasks.md | 14 -
.../.openspec.yaml | 2 -
.../design.md | 51 --
.../proposal.md | 30 --
.../specs/replayable-command-remappings/spec.md | 74 ---
.../tasks.md | 14 -
.../.openspec.yaml | 2 -
.../design.md | 89 ----
.../proposal.md | 31 --
.../specs/command-export-known-targets/spec.md | 80 ---
.../specs/command-export-yaml-result/spec.md | 34 --
.../specs/safe-action-command-publishing/spec.md | 31 --
.../tasks.md | 38 --
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 24 -
.../specs/command-export-yaml-result/spec.md | 22 -
.../tasks.md | 13 -
.../.openspec.yaml | 2 -
.../design.md | 66 ---
.../proposal.md | 30 --
.../specs/command-replay-result-mapping/spec.md | 27 -
.../specs/replayable-command-remappings/spec.md | 103 ----
.../2026-06-07-show-replayable-remappings/tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 36 --
.../proposal.md | 32 --
.../specs/replayable-command-remappings/spec.md | 35 --
.../tasks.md | 22 -
.../.openspec.yaml | 2 -
.../design.md | 71 ---
.../proposal.md | 28 --
.../specs/command-recording-suppression/spec.md | 60 ---
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 69 ---
.../proposal.md | 29 --
.../specs/command-recording-suppression/spec.md | 54 --
.../parented-collection-selector-actions/spec.md | 94 ----
.../specs/safe-action-command-publishing/spec.md | 43 --
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../2026-06-08-add-move-commands-action/design.md | 74 ---
.../proposal.md | 28 --
.../command-export-command-reordering/spec.md | 80 ---
.../specs/command-export-known-targets/spec.md | 47 --
.../2026-06-08-add-move-commands-action/tasks.md | 50 --
.../.openspec.yaml | 2 -
.../design.md | 61 ---
.../proposal.md | 27 -
.../command-export-command-reordering/spec.md | 227 ---------
.../tasks.md | 26 -
.../.openspec.yaml | 2 -
.../design.md | 70 ---
.../proposal.md | 26 -
.../specs/command-export-known-targets/spec.md | 49 --
.../specs/replayable-command-exportability/spec.md | 34 --
.../tasks.md | 32 --
.../.openspec.yaml | 2 -
.../design.md | 52 --
.../proposal.md | 27 -
.../command-export-command-reordering/spec.md | 39 --
.../tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 54 --
.../proposal.md | 27 -
.../specs/command-export-known-targets/spec.md | 261 ----------
.../spec.md | 32 --
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 25 -
.../command-export-manager-command-list/spec.md | 30 --
.../tasks.md | 18 -
.../.openspec.yaml | 2 -
.../design.md | 86 ----
.../proposal.md | 29 --
.../specs/command-replay-result-mapping/spec.md | 42 --
.../tasks.md | 33 --
.../.openspec.yaml | 2 -
.../design.md | 54 --
.../proposal.md | 27 -
.../specs/command-export-refdata-marker/spec.md | 46 --
.../spec.md | 41 --
.../tasks.md | 26 -
.../.openspec.yaml | 2 -
.../2026-06-08-delete-excluded-commands/design.md | 51 --
.../proposal.md | 25 -
.../specs/command-export-command-exclusion/spec.md | 56 ---
.../2026-06-08-delete-excluded-commands/tasks.md | 33 --
.../.openspec.yaml | 2 -
.../2026-06-08-exclude-recorded-commands/design.md | 67 ---
.../proposal.md | 28 --
.../specs/command-export-command-exclusion/spec.md | 91 ----
.../command-export-command-reordering/spec.md | 81 ---
.../command-export-manager-command-list/spec.md | 63 ---
.../2026-06-08-exclude-recorded-commands/tasks.md | 37 --
.../.openspec.yaml | 2 -
.../design.md | 59 ---
.../proposal.md | 24 -
.../specs/command-export-known-targets/spec.md | 120 -----
.../tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 37 --
.../proposal.md | 24 -
.../command-export-command-reordering/spec.md | 50 --
.../tasks.md | 24 -
.../.openspec.yaml | 2 -
.../design.md | 63 ---
.../proposal.md | 29 --
.../specs/replayable-command-exportability/spec.md | 17 -
.../specs/replayable-command-navigation/spec.md | 47 --
.../spec.md | 74 ---
.../replayable-command-result-presence/spec.md | 39 --
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../design.md | 55 ---
.../proposal.md | 27 -
.../command-replay-background-completion/spec.md | 42 --
.../specs/replayable-command-actions/spec.md | 65 ---
.../tasks.md | 28 --
.../.openspec.yaml | 2 -
.../design.md | 72 ---
.../proposal.md | 26 -
.../specs/command-export-yaml-result/spec.md | 38 --
.../specs/safe-action-command-publishing/spec.md | 38 --
.../tasks.md | 33 --
.../.openspec.yaml | 2 -
.../design.md | 57 ---
.../proposal.md | 26 -
.../spec.md | 42 --
.../tasks.md | 20 -
.../.openspec.yaml | 2 -
.../design.md | 46 --
.../proposal.md | 25 -
.../command-export-manager-command-list/spec.md | 12 -
.../tasks.md | 17 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 24 -
.../specs/command-export-known-targets/spec.md | 44 --
.../specs/replayable-command-exportability/spec.md | 38 --
.../tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 79 ---
.../proposal.md | 30 --
.../specs/command-export-known-targets/spec.md | 56 ---
.../tasks.md | 38 --
.../.openspec.yaml | 2 -
.../design.md | 49 --
.../proposal.md | 28 --
.../command-export-command-reordering/spec.md | 61 ---
.../specs/command-export-known-targets/spec.md | 56 ---
.../command-export-manager-command-list/spec.md | 64 ---
.../tasks.md | 28 --
.../.openspec.yaml | 2 -
.../design.md | 54 --
.../proposal.md | 30 --
.../command-export-manager-command-list/spec.md | 45 --
.../specs/command-replay-result-mapping/spec.md | 26 -
.../specs/replayable-command-eligibility/spec.md | 33 --
.../specs/safe-action-command-publishing/spec.md | 36 --
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 54 --
.../proposal.md | 25 -
.../specs/command-export-command-exclusion/spec.md | 68 ---
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 68 ---
.../proposal.md | 30 --
.../specs/command-replay-result-mapping/spec.md | 46 --
.../tasks.md | 24 -
.../.openspec.yaml | 2 -
.../design.md | 76 ---
.../proposal.md | 26 -
.../specs/command-recording-suppression/spec.md | 37 --
.../specs/property-edit-recording/spec.md | 56 ---
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../design.md | 47 --
.../proposal.md | 26 -
.../parented-collection-selector-actions/spec.md | 45 --
.../tasks.md | 24 -
.../.openspec.yaml | 2 -
.../design.md | 97 ----
.../proposal.md | 32 --
.../parented-collection-selector-actions/spec.md | 55 ---
.../tasks.md | 30 --
.../.openspec.yaml | 2 -
.../2026-09-08-add-wicket-motd-banner/design.md | 87 ----
.../2026-09-08-add-wicket-motd-banner/proposal.md | 29 --
.../specs/wicket-footer-motd/spec.md | 97 ----
.../2026-09-08-add-wicket-motd-banner/tasks.md | 23 -
.../.openspec.yaml | 2 -
.../design.md | 136 -----
.../proposal.md | 33 --
.../specs/boot27-observation-substrate/spec.md | 75 ---
.../tasks.md | 28 --
.../.openspec.yaml | 2 -
.../design.md | 90 ----
.../proposal.md | 29 --
.../boot27-micrometer-tracing-operations/spec.md | 100 ----
.../tasks.md | 31 --
.../.openspec.yaml | 2 -
.../design.md | 74 ---
.../proposal.md | 29 --
.../secman-jpa-association-consistency/spec.md | 45 --
.../tasks.md | 20 -
.../.openspec.yaml | 2 -
.../design.md | 103 ----
.../proposal.md | 31 --
.../root-interaction-action-observability/spec.md | 69 ---
.../tasks.md | 27 -
.../.openspec.yaml | 2 -
.../design.md | 115 -----
.../evidence/compatibility-results.md | 101 ----
.../proposal.md | 31 --
.../spec.md | 43 --
.../tasks.md | 25 -
.../.openspec.yaml | 2 -
.../design.md | 94 ----
.../proposal.md | 30 --
.../spec.md | 78 ---
.../tasks.md | 30 --
.../.openspec.yaml | 2 -
.../design.md | 81 ---
.../proposal.md | 31 --
.../current-action-invocation-context/spec.md | 108 ----
.../tasks.md | 20 -
.../spec.md | 46 --
.../boot27-micrometer-tracing-operations/spec.md | 104 ----
.../specs/boot27-observation-substrate/spec.md | 78 ---
.../specs/command-export-command-exclusion/spec.md | 204 --------
.../command-export-command-reordering/spec.md | 191 -------
.../specs/command-export-known-targets/spec.md | 340 -------------
.../command-export-manager-command-list/spec.md | 189 -------
.../specs/command-export-refdata-marker/spec.md | 50 --
.../spec.md | 45 --
openspec/specs/command-export-yaml-result/spec.md | 178 -------
.../spec.md | 46 --
.../specs/command-recording-suppression/spec.md | 128 -----
.../command-replay-background-completion/spec.md | 47 --
.../specs/command-replay-result-mapping/spec.md | 286 -----------
.../current-action-invocation-context/spec.md | 108 ----
.../spec.md | 94 ----
.../spec.md | 83 ----
.../parented-collection-selector-actions/spec.md | 550 ---------------------
.../spec.md | 211 --------
openspec/specs/property-edit-recording/spec.md | 60 ---
openspec/specs/replayable-command-actions/spec.md | 63 ---
.../specs/replayable-command-eligibility/spec.md | 55 ---
.../specs/replayable-command-exportability/spec.md | 91 ----
.../specs/replayable-command-navigation/spec.md | 51 --
.../spec.md | 77 ---
.../specs/replayable-command-remappings/spec.md | 224 ---------
.../replayable-command-result-presence/spec.md | 43 --
.../root-interaction-action-observability/spec.md | 73 ---
.../specs/safe-action-command-publishing/spec.md | 153 ------
.../secman-jpa-association-consistency/spec.md | 48 --
openspec/specs/wicket-footer-motd/spec.md | 101 ----
476 files changed, 20154 deletions(-)
diff --git a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/.openspec.yaml b/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/design.md b/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/design.md
deleted file mode 100644
index 164ed34bff6..00000000000
--- a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/design.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Context
-
-The command log applib provides `CommandReplayMappingListenerDefault` as the conditional default implementation of `CommandReplayMappingListener`.
-It records non-identity replay result mappings in memory and uses them to remap later replay inputs.
-The current conflict behavior is strict: when a recorded result bookmark already has a remembered actual bookmark and replay reports a different actual bookmark, the default listener throws an exception.
-Because result mapping notification runs in the same transaction as replay execution, that exception causes the replayed command to fail and roll back.
-
-Some users want this fail-fast protection, while other replay workflows prefer to keep the first mapping, log the conflict, and continue processing.
-The new option should therefore be a property-driven policy on the default listener rather than a change to the SPI contract.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Preserve strict conflict rejection as the default behavior.
-- Allow applications to configure a lenient conflict policy that logs and continues.
-- Keep the existing recorded-to-actual mapping unchanged when a conflict is ignored.
-- Keep custom `CommandReplayMappingListener` implementations unaffected.
-- Make the property available through the standard `CausewayConfiguration` binding model.
-
-**Non-Goals:**
-
-- Do not change the `CommandReplayMappingListener` SPI methods.
-- Do not make the default listener persist mappings.
-- Do not add per-command or runtime UI controls for conflict behavior.
-- Do not change replay transaction boundaries.
-
-## Decisions
-
-- Add a nested configuration property for default replay mapping listener conflict handling under the command log extension configuration.
- A concrete shape such as `CausewayConfiguration.Extensions.CommandLog.ReplayResultMapping` with `onConflictPolicy` keeps the option near the extension that owns the default listener.
- The external property name should follow existing relaxed binding conventions, for example `causeway.extensions.command-log.replay-result-mapping.on-conflict-policy`.
-
-- Represent behavior with an enum rather than a boolean.
- Suggested values are `THROW_EXCEPTION` and `LOG_AND_CONTINUE`.
- This mirrors existing policy-style configuration such as background command `OnFailurePolicy` and leaves room for additional behaviors without renaming the property.
-
-- Inject `CausewayConfiguration` into `CommandReplayMappingListenerDefault` or its factory and pass the selected policy into the listener.
- This keeps the policy centralized and avoids introducing a separate application bean just to configure the default listener.
-
-- In `THROW_EXCEPTION`, preserve the current behavior exactly.
- The listener throws and keeps the existing mapping unchanged.
-
-- In `LOG_AND_CONTINUE`, log the recorded bookmark, existing actual bookmark, and conflicting actual bookmark at error level, keep the existing mapping unchanged, and return without throwing.
- This lets replay continue while still leaving an operational signal that the replay stream is inconsistent.
-
-## Risks / Trade-offs
-
-- Lenient mode can hide replay data inconsistency if logs are not monitored.
- Mitigation: keep strict mode as the default and log conflicts at error level in lenient mode.
-
-- The property path might be confused with the separate command replay configuration namespace.
- Mitigation: document the property in tests and code comments around the default command log listener.
-
-- Injecting configuration into the default listener factory changes construction in tests.
- Mitigation: update unit tests to cover explicit policy construction and Spring bean creation with default configuration.
diff --git a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/proposal.md b/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/proposal.md
deleted file mode 100644
index c894f3be2d1..00000000000
--- a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/proposal.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Why
-
-The default replay mapping listener currently always fails replay when the same recorded bookmark later maps to a different actual bookmark.
-Some import/replay workflows need the strict behavior for safety, while others prefer to log conflicting mappings and continue processing subsequent commands.
-
-## What Changes
-
-- Add a configuration property that controls how the default command replay mapping listener handles conflicting replay result mappings.
-- Keep the current strict behavior as the default, so a conflicting mapping throws an exception and fails replay.
-- Add an alternative lenient behavior that logs the conflicting mapping and continues without replacing the existing recorded-to-actual mapping.
-- Document the accepted property values and the default value.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `default-command-replay-mapping-listener`: Make conflict handling configurable while preserving strict conflict rejection as the default behavior.
-
-## Impact
-
-- Affects the command log applib default `CommandReplayMappingListener` implementation and its autoconfiguration.
-- Adds a new command log configuration property, likely under the extensions command log replay namespace.
-- Updates unit tests for strict default behavior and lenient log-and-continue behavior.
-- No breaking changes are expected because the current exception-throwing behavior remains the default.
diff --git a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/specs/default-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/specs/default-command-replay-mapping-listener/spec.md
deleted file mode 100644
index e0e75425569..00000000000
--- a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/specs/default-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Default replay mapping listener records result mappings
-The system SHALL provide a default command replay mapping listener that records each replay result mapping by recorded result bookmark.
-When replay notifies the listener with a recorded result bookmark and a different actual result bookmark, the listener SHALL remember the actual bookmark for the recorded bookmark if no mapping already exists.
-When replay notifies the listener with equal recorded and actual result bookmarks, the listener MUST NOT remember a mapping for that notification.
-When the same recorded bookmark is notified more than once with the same actual result bookmark, the listener SHALL treat the notification as idempotent.
-When the same recorded bookmark is notified more than once with different actual result bookmarks, the listener SHALL apply its configured conflict policy and MUST NOT replace the remembered actual bookmark.
-The system SHALL default the conflict policy to throwing an exception.
-The system SHALL provide a configuration property that can change the conflict policy to log the conflict and continue.
-
-#### Scenario: Different result mapping is recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener records `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Equal result mapping is not recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the default listener records no mapping for `demoInvoice:1`
-
-#### Scenario: Result mapping is repeated with the same actual bookmark
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-- **AND** no exception is thrown
-
-#### Scenario: Result mapping conflict is rejected by default
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener throws an exception
-- **AND** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Result mapping conflict is logged and ignored when configured
-- **GIVEN** the default listener conflict policy is configured to log and continue
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener logs the conflict
-- **AND** no exception is thrown
-- **AND** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
diff --git a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/tasks.md b/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/tasks.md
deleted file mode 100644
index 6dd03419608..00000000000
--- a/openspec/changes/archive/2026-06-04-configure-replay-result-conflict-handling/tasks.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## 1. Configuration Model
-
-- [x] 1.1 Add a command log replay result mapping conflict policy enum with strict and log-and-continue values.
-- [x] 1.2 Add a `CausewayConfiguration` property for the default listener conflict policy with strict throwing behavior as the default.
-- [x] 1.3 Document the property name and accepted values in code comments or generated configuration metadata if applicable.
-
-## 2. Default Listener Behavior
-
-- [x] 2.1 Update `CommandReplayMappingListenerDefault` construction to receive the configured conflict policy.
-- [x] 2.2 Preserve the existing exception-throwing conflict behavior when the policy is strict.
-- [x] 2.3 Implement the log-and-continue policy so conflicts are logged and the existing mapping is retained without throwing.
-- [x] 2.4 Update the default listener bean factory to obtain the policy from `CausewayConfiguration`.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Update default listener unit tests to verify strict conflict handling remains the default.
-- [x] 3.2 Add unit tests for the log-and-continue policy, including retained original mapping and no thrown exception.
-- [x] 3.3 Add or update bean factory tests to verify configuration is passed into the default listener.
-- [x] 3.4 Run the command log applib test suite covering `CommandReplayMappingListenerDefaultTest` and `ReplayableCommandMappingTest`.
-- [x] 3.5 Run `openspec validate configure-replay-result-conflict-handling --type change --strict`.
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/.openspec.yaml b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/design.md b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/design.md
deleted file mode 100644
index dd100090866..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/design.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Context
-
-The command replay mapping SPI already lets applications remap replay targets and reference parameters, and it notifies listeners after a successful replay maps a recorded result bookmark to an actual result bookmark.
-The common replay workflow needs those result mappings to be remembered so that later commands can remap inputs that refer to objects created or otherwise mapped by earlier replayed commands.
-Today the SPI provides the hooks, but applications must supply their own listener before replay input remapping can use mappings observed earlier in the same replay session.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Provide a default `CommandReplayMappingListener` implementation that stores recorded-to-actual replay result mappings in memory.
-- Make the default implementation available through autoconfiguration only when an application has not defined another listener bean.
-- Keep the listener behavior simple, deterministic, and aligned with the existing SPI methods.
-- Preserve custom application listeners as the extension point for persistent, distributed, or domain-specific mapping behavior.
-
-**Non-Goals:**
-
-- Persist replay mappings across JVM restarts or application nodes.
-- Change the `CommandReplayMappingListener` SPI method signatures.
-- Replace user-defined listener beans or combine multiple default mapping stores.
-- Resolve bookmarks to live domain objects before storing or remapping them.
-
-## Decisions
-
-- Implement the default listener as a command log extension class that implements `CommandReplayMappingListener` directly.
- This keeps the behavior close to the SPI and avoids adding a new service abstraction for simple map-backed state.
- An alternative was to add a separate mapping store service, but that would add indirection without current persistence or distribution requirements.
-
-- Use a simple in-memory `HashMap<Bookmark, Bookmark>` keyed by the recorded bookmark and valued by the actual replay bookmark.
- `onReplayResultMapped(...)` will update the map only when the actual bookmark differs from the recorded bookmark, and `remap(...)` will return the mapped actual bookmark when present.
- Equal recorded and actual bookmarks do not need saved mappings because replay can keep using the recorded bookmark unchanged.
- An alternative was to store identity mappings too, but that would grow the map without changing later remapping behavior.
- Another alternative was to use a concurrent map, but command replay is expected to use this listener in a straightforward replay flow and the requested implementation explicitly calls for a simple hashmap.
-
-- Register the default listener with Spring Boot autoconfiguration guarded by `@ConditionalOnMissingBean(CommandReplayMappingListener.class)`.
- This lets applications override the default by declaring their own listener bean while giving simpler applications out-of-the-box remapping behavior.
- An alternative was unconditional registration, but that would interfere with custom listener implementations and could create multiple mapping listeners with overlapping behavior.
-
-- Keep the default map lifecycle bound to the Spring bean lifecycle.
- This matches the requirement for a simple default implementation and avoids adding clearing, scoping, or persistence semantics in this change.
- Applications that need different lifecycle semantics can provide their own listener bean.
-
-## Risks / Trade-offs
-
-- In-memory mappings are lost on restart or bean recreation → Document the default as an in-memory convenience and leave durable behavior to custom listener beans.
-- A singleton map can retain mappings longer than a replay batch → Keep the implementation simple for this change and rely on custom listeners where tighter scoping is required.
-- Multiple replay batches in the same JVM could observe previous mappings → Use recorded bookmark keys so repeated mappings overwrite previous values, and avoid claiming batch isolation for the default implementation.
-- `HashMap` is not thread-safe → Treat the default as suitable for simple replay use and allow applications with concurrent replay requirements to replace it with their own bean.
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/proposal.md b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/proposal.md
deleted file mode 100644
index 27b6faae79a..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Applications that replay imported commands need a ready-to-use mapping listener for the common case where replay result mappings should feed later input remapping.
-Without a default implementation, each application must repeat the same simple in-memory bookkeeping before command replay input remapping works out of the box.
-
-## What Changes
-
-- Add a default command replay mapping listener implementation backed by a simple in-memory `HashMap` from recorded bookmarks to actual replay result bookmarks.
-- Record mappings when replay reports `onReplayResultMapped(...)` and the actual bookmark differs from the recorded bookmark, then consult the recorded-to-actual map from `remap(...)` before command execution.
-- Register the default listener through Spring Boot autoconfiguration only when no other `CommandReplayMappingListener` bean is present.
-- Leave existing custom listener implementations in control by ensuring the default bean is conditional on missing bean.
-
-## Capabilities
-
-### New Capabilities
-
-- `default-command-replay-mapping-listener`: Provides an out-of-the-box replay mapping listener that remembers replay result mappings and remaps later replay inputs from those mappings.
-
-### Modified Capabilities
-
-- `command-replay-result-mapping`: The replay mapping SPI gains a default autoconfigured implementation when applications do not provide their own listener.
-
-## Impact
-
-- Affects the command log extension applib/autoconfiguration modules that expose and wire `CommandReplayMappingListener`.
-- Adds a default Spring bean, guarded by `@ConditionalOnMissingBean`, without changing the SPI method signatures.
-- Uses in-memory state, so mappings are scoped to the lifecycle of the default listener bean and are not persisted.
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index c75309fe0f1..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,18 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay mapping SPI has a conditional default listener
-The system SHALL autoconfigure a default `CommandReplayMappingListener` bean when no application-defined `CommandReplayMappingListener` bean is present.
-The system MUST NOT instantiate the default listener bean when another `CommandReplayMappingListener` bean is already defined.
-The conditional default listener SHALL participate in the same replay mapping listener collection used for replay input remapping and replay result mapping notifications.
-
-#### Scenario: Default listener is autoconfigured when missing
-- **WHEN** the application context contains no `CommandReplayMappingListener` bean
-- **THEN** the command log autoconfiguration provides the default `CommandReplayMappingListener` bean
-
-#### Scenario: Default listener backs off for custom listener
-- **WHEN** the application context already contains a custom `CommandReplayMappingListener` bean
-- **THEN** the command log autoconfiguration does not provide the default `CommandReplayMappingListener` bean
-
-#### Scenario: Autoconfigured listener participates in replay
-- **WHEN** the command log autoconfiguration provides the default `CommandReplayMappingListener` bean
-- **THEN** command replay includes that listener when requesting input remaps and sending result mapping notifications
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md
deleted file mode 100644
index aa0fa5df820..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Default replay mapping listener records result mappings
-The system SHALL provide a default command replay mapping listener that records each replay result mapping by recorded result bookmark.
-When replay notifies the listener with a recorded result bookmark and a different actual result bookmark, the listener SHALL remember the actual bookmark for the recorded bookmark.
-When replay notifies the listener with equal recorded and actual result bookmarks, the listener MUST NOT remember a mapping for that notification.
-When the same recorded bookmark is notified more than once with different actual result bookmarks, the listener SHALL use the most recent actual bookmark for later remapping.
-
-#### Scenario: Different result mapping is recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener records `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Equal result mapping is not recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the default listener records no mapping for `demoInvoice:1`
-
-#### Scenario: Result mapping is replaced
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener records `demoInvoice:3` as the actual bookmark for `demoInvoice:1`
-
-### Requirement: Default replay mapping listener remaps from recorded results
-The default command replay mapping listener SHALL return a remembered actual bookmark when replay asks it to remap a recorded bookmark that was previously stored from a replay result mapping.
-When no mapping is remembered for the recorded bookmark, the listener SHALL return no replacement.
-The listener SHALL perform remapping without resolving recorded or actual bookmarks to live domain objects.
-
-#### Scenario: Recorded bookmark is remapped from stored mapping
-- **WHEN** the default listener has recorded that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** command replay asks the listener to remap recorded bookmark `demoInvoice:1`
-- **THEN** the default listener returns replacement bookmark `demoInvoice:2`
-
-#### Scenario: Unmapped recorded bookmark is not replaced
-- **WHEN** the default listener has no recorded mapping for bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to remap recorded bookmark `demoInvoice:1`
-- **THEN** the default listener returns no replacement
-
-### Requirement: Default replay mapping listener uses in-memory state
-The default command replay mapping listener SHALL store mappings in memory only.
-The system SHALL NOT require the default listener to persist mappings across JVM restarts, application nodes, or Spring bean lifecycle recreation.
-
-#### Scenario: Mapping state is scoped to listener instance
-- **WHEN** the default listener records that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** a new default listener instance is created
-- **THEN** the new listener instance has no required remembered mapping for `demoInvoice:1`
diff --git a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/tasks.md b/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/tasks.md
deleted file mode 100644
index a481c0d8efd..00000000000
--- a/openspec/changes/archive/2026-06-04-default-command-replay-mapping-listener/tasks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 1. Default Listener Implementation
-
-- [x] 1.1 Add a default `CommandReplayMappingListener` implementation in the command log applib that stores recorded-to-actual mappings in a `HashMap<Bookmark, Bookmark>`.
-- [x] 1.2 Implement `onReplayResultMapped(...)` to store or replace the actual bookmark for the recorded result bookmark.
-- [x] 1.3 Implement `remap(...)` to return the remembered actual bookmark for a recorded bookmark, or `Optional.empty()` when none exists.
-- [x] 1.4 Keep the implementation bookmark-based and avoid resolving recorded or actual bookmarks to domain objects.
-
-## 2. Autoconfiguration
-
-- [x] 2.1 Register the default listener as a Spring bean from the command log applib module configuration.
-- [x] 2.2 Guard the bean with `@ConditionalOnMissingBean(CommandReplayMappingListener.class)` so custom listener beans replace the default.
-- [x] 2.3 Ensure the autoconfigured listener is available to the existing replay listener collection used by `ReplayContext`.
-
-## 3. Tests
-
-- [x] 3.1 Add unit tests proving the default listener records result mappings and returns them from `remap(...)`.
-- [x] 3.2 Add a unit test proving a repeated recorded bookmark mapping uses the latest actual bookmark.
-- [x] 3.3 Add a unit test proving an unmapped bookmark returns no replacement.
-- [x] 3.4 Add Spring context tests proving the default listener bean is created when missing and backs off when a custom listener bean exists.
-
-## 4. Verification
-
-- [x] 4.1 Run the command log applib test suite for the new listener and autoconfiguration coverage.
-- [x] 4.2 Run `openspec validate --change default-command-replay-mapping-listener --strict`.
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/.openspec.yaml b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/design.md b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/design.md
deleted file mode 100644
index 5b7ac9b61bb..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/design.md
+++ /dev/null
@@ -1,66 +0,0 @@
-## Context
-
-Command replay imports recorded command DTOs and re-executes them locally.
-The replay mapping SPI lets applications remap replay inputs and observe mappings from recorded result bookmarks to actual replay result bookmarks.
-
-The current replay flow executes the command in one `REQUIRES_NEW` transaction and then handles replay success or failure in a second `REQUIRES_NEW` transaction.
-Result-mapping listener notification happens in the second transaction, and listener exceptions are caught and logged.
-That means a listener consistency failure cannot fail or roll back the replayed command.
-
-The default listener stores mappings in an in-memory `HashMap<Bookmark, Bookmark>` keyed by recorded result bookmark.
-It currently replaces an existing mapping with the latest actual bookmark.
-For replay consistency, a recorded original result that was already mapped to one actual bookmark must not later be mapped to a different actual bookmark.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Detect conflicting result mappings in the default listener.
-- Make repeated identical result mappings idempotent.
-- Keep ignoring identity mappings where recorded and actual bookmarks are equal.
-- Run replay execution, success bookkeeping, and result-mapping listener notification in one transaction.
-- Propagate result-mapping listener exceptions so consistency failures mark replay as failed and prevent successful command execution.
-
-**Non-Goals:**
-
-- Do not persist default listener mappings beyond the existing in-memory listener instance.
-- Do not change the `CommandReplayMappingListener` method signatures.
-- Do not change target or reference parameter remapping exception handling before command execution.
-- Do not introduce distributed coordination for mapping state across JVMs or nodes.
-
-## Decisions
-
-### Use the default listener as the consistency guard
-
-The default listener already owns the in-memory recorded-to-actual result map.
-It will inspect the existing mapping before writing a new non-identity mapping.
-If the recorded result has no existing mapping, it records the actual result.
-If the existing mapping equals the new actual result, it leaves the map unchanged and returns normally.
-If the existing mapping differs from the new actual result, it throws an exception with the conflicting bookmarks.
-
-An alternative was to let the latest mapping continue to win and add a separate audit warning.
-That would not protect downstream remapping from ambiguous original results, so it is rejected.
-
-### Notify result-mapping listeners inside the replay command transaction
-
-`ReplayableCommand` will move successful replay bookkeeping and result-mapping listener notification into the transaction that calls `CommandExecutorService#executeCommand(...)`.
-The command execution result bookmark is available before that transaction returns, so the replay can save success analysis and notify listeners before commit.
-If a listener throws, the transaction fails and the command replay result is reported as a failure.
-
-An alternative was to keep the second transaction and rethrow listener exceptions there.
-That would fail the post-processing transaction but still leave the replayed command execution committed, which does not satisfy the consistency requirement.
-
-### Keep replay failure bookkeeping in a separate transaction
-
-When command execution or listener notification fails, the existing failure bookkeeping still needs to save replay analysis on the imported command log entry.
-That failure analysis should run after the failed command transaction has rolled back, using a separate transaction as today.
-Success bookkeeping does not need a second transaction because it now belongs to the successful command transaction.
-
-## Risks / Trade-offs
-
-- Custom listeners that previously threw without affecting replay will now cause replay failure.
- → This is intentional for result-mapping notifications; document it in tests and specs.
-- Failure analysis still depends on a follow-up transaction after rollback.
- → Preserve the existing failure handling pattern for replay errors.
-- The default listener remains in-memory and is not synchronized across application nodes.
- → This change only strengthens consistency for one listener instance, matching the current non-persistence scope.
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/proposal.md b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/proposal.md
deleted file mode 100644
index 1dbfd4d55cc..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/proposal.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## Why
-
-The default command replay mapping listener currently allows a recorded result bookmark to be overwritten with a later, different actual bookmark.
-That can hide replay divergence and allow downstream commands to remap against an ambiguous original result.
-
-Replay also currently handles replay execution and listener notification in separate transactions.
-A listener failure during result mapping therefore cannot make the command replay itself fail, which prevents consistency checks from protecting the replay outcome.
-
-## What Changes
-
-- Update the default command replay mapping listener to reject conflicting result mappings for the same recorded result bookmark.
-- Treat a repeated notification for the same recorded result and the same actual result as idempotent.
-- Keep ignoring identity mappings where recorded and actual bookmarks are equal.
-- Change replay transaction handling so replay execution, success bookkeeping, and result-mapping listener notification run in the same command transaction.
-- Let result-mapping listener exceptions propagate so a failed consistency check causes command replay execution to fail.
-- Continue not notifying result-mapping listeners when replay fails or when recorded or actual result bookmarks are unavailable.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `command-replay-result-mapping`: Result-mapping listener failures must fail the replayed command, and listener notification must occur in the same transaction as command execution.
-- `default-command-replay-mapping-listener`: The default listener must reject conflicting actual bookmarks for a recorded result bookmark.
-
-## Impact
-
-- Affects command replay transaction flow in the command log applib replay implementation.
-- Affects `CommandReplayMappingListenerDefault` behavior for repeated mappings.
-- Affects tests for replay listener exception handling and default listener consistency.
-- Existing applications with custom listeners that throw from result mapping will now cause replay command execution to fail instead of only logging a warning.
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 141578bf8ef..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replay result mapping SPI is notified after successful replay
-The system SHALL provide a command replay mapping SPI that applications can implement to receive replay result bookmark mappings and provide replay input remappings.
-After a command replay succeeds, the system SHALL notify the SPI when the imported command log entry has a recorded returned object bookmark and replay execution returns an actual result bookmark.
-The notification SHALL include the recorded returned object bookmark and the actual replay result bookmark.
-The system SHALL notify the SPI in the same transaction as replay command execution.
-The system SHALL propagate result-mapping notification exceptions so the replayed command execution fails and rolls back.
-
-#### Scenario: Successful replay produces a different result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Successful replay produces the same result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:1`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-#### Scenario: Result mapping listener rejects the replay result
-- **WHEN** command replay execution succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **AND** a command replay mapping SPI throws while handling the result mapping notification
-- **THEN** the replayed command execution fails
-- **AND** the replayed command transaction rolls back
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/default-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/default-command-replay-mapping-listener/spec.md
deleted file mode 100644
index 866abd303cd..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/specs/default-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Default replay mapping listener records result mappings
-The system SHALL provide a default command replay mapping listener that records each replay result mapping by recorded result bookmark.
-When replay notifies the listener with a recorded result bookmark and a different actual result bookmark, the listener SHALL remember the actual bookmark for the recorded bookmark if no mapping already exists.
-When replay notifies the listener with equal recorded and actual result bookmarks, the listener MUST NOT remember a mapping for that notification.
-When the same recorded bookmark is notified more than once with the same actual result bookmark, the listener SHALL treat the notification as idempotent.
-When the same recorded bookmark is notified more than once with different actual result bookmarks, the listener SHALL throw an exception and MUST NOT replace the remembered actual bookmark.
-
-#### Scenario: Different result mapping is recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener records `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Equal result mapping is not recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the default listener records no mapping for `demoInvoice:1`
-
-#### Scenario: Result mapping is repeated with the same actual bookmark
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-- **AND** no exception is thrown
-
-#### Scenario: Result mapping conflict is rejected
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener throws an exception
-- **AND** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
diff --git a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/tasks.md b/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/tasks.md
deleted file mode 100644
index 025247df1f2..00000000000
--- a/openspec/changes/archive/2026-06-04-fail-replay-on-conflicting-result-mapping/tasks.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## 1. Default Listener Consistency
-
-- [x] 1.1 Update `CommandReplayMappingListenerDefault#onReplayResultMapped(...)` to check for an existing non-identity mapping before writing.
-- [x] 1.2 Throw an exception when a recorded result bookmark is already mapped to a different actual bookmark.
-- [x] 1.3 Preserve idempotent behavior when a repeated notification uses the same actual bookmark.
-- [x] 1.4 Preserve no-op behavior when recorded and actual bookmarks are equal.
-
-## 2. Replay Transaction Handling
-
-- [x] 2.1 Refactor `ReplayableCommand#tryReplay(...)` so command execution and successful result-mapping notification happen inside the same `REQUIRES_NEW` transaction.
-- [x] 2.2 Preserve separate failure-analysis persistence after the failed command transaction rolls back.
-- [x] 2.3 Remove exception swallowing for result-mapping notification failures so listener exceptions propagate from the command transaction.
-- [x] 2.4 Keep target and reference parameter remapping exception handling unchanged.
-
-## 3. Tests
-
-- [x] 3.1 Update default listener tests to cover conflict rejection, idempotent duplicate notification, and unchanged mapping after conflict.
-- [x] 3.2 Update replay mapping tests to verify result-mapping listener exceptions fail replay execution.
-- [x] 3.3 Add or update transaction-service test stubbing to verify successful listener notification happens in the same transaction as command execution.
-- [x] 3.4 Verify missing recorded or actual result bookmarks still skip result-mapping notification.
-
-## 4. Verification
-
-- [x] 4.1 Run the command log applib tests that cover `CommandReplayMappingListenerDefaultTest` and `ReplayableCommandMappingTest`.
-- [x] 4.2 Run `openspec validate fail-replay-on-conflicting-result-mapping --type change --strict`.
diff --git a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/.openspec.yaml b/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/design.md b/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/design.md
deleted file mode 100644
index fab85038cf4..00000000000
--- a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/design.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## Context
-
-`CommandExportManager_exportSelected` currently builds an export file by mapping selected `ReplayableCommand` instances back to their `CommandLogEntry` entities and serializing only `CommandLogEntry#getCommandDto()` through `CommandDtoUtils.toYaml(...)`.
-`CommandLogEntry` already persists the returned object as a `Bookmark` via `getResult()`, while the command DTO includes target OIDs in a `logicalTypeName` plus `id` form.
-The requested change is additive: export consumers need the returned object alongside the command information, but replay import should continue to rely on the command DTO payload.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add returned object metadata to each exported command when the command log entry has a result bookmark.
-- Use a returned object representation that mirrors target identity fields: `logicalTypeName` and `id`.
-- Keep the exported YAML readable and deterministic for tests and users.
-- Preserve import compatibility for existing command replay workflows.
-
-**Non-Goals:**
-
-- Do not change how command execution captures or persists `CommandLogEntry#getResult()`.
-- Do not change replay semantics to use the returned object during command execution.
-- Do not introduce a new external YAML dependency.
-- Do not backfill returned object metadata into historical export files.
-
-## Decisions
-
-- Introduce an export-specific wrapper record rather than mutating `CommandDto`.
- This keeps replay DTO semantics stable and avoids adding result metadata to the schema-backed command DTO model.
- Alternative considered: storing result metadata in `CommandDto` user data, but that would blur replay input with export diagnostics and could affect import behavior.
-
-- Serialize target and returned object bookmarks using the same two fields, `logicalTypeName` and `id`.
- This matches the user's requested shape and follows the existing command target identity naming convention.
- Alternative considered: serializing `Bookmark#toString()`, but that is less structured and harder to assert in YAML tests.
-
-- Omit the returned object block when `CommandLogEntry#getResult()` is null.
- This keeps void command exports concise and follows existing non-null YAML serialization conventions.
- Alternative considered: always emit `returnedObject: null`, but that adds noise without improving replay behavior.
-
-- Keep import tolerant by extracting command DTOs from either the new wrapper form or the legacy bare command DTO list if import support needs to read freshly exported files.
- This protects replay workflows while allowing the export file shape to evolve.
- Alternative considered: changing export only and leaving import untouched, but that could surprise users who export and immediately import the same YAML.
-
-## Risks / Trade-offs
-
-- [Risk] Existing consumers may expect a top-level YAML list of command DTOs only.
- Mitigation: Keep command DTO content intact and, where import is in scope, support both the new wrapper and legacy list shapes.
-
-- [Risk] The returned object bookmark may refer to an object that no longer exists on an importing system.
- Mitigation: Treat returned object metadata as informational export data, not replay input.
-
-- [Risk] YAML field naming could diverge from existing command target naming.
- Mitigation: Use explicit `logicalTypeName` and `id` fields and add assertions for exact YAML output.
diff --git a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/proposal.md b/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/proposal.md
deleted file mode 100644
index 3745548266f..00000000000
--- a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/proposal.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## Why
-
-Command export YAML currently serializes each selected `CommandLogEntry` through its underlying `CommandDto`, which includes the command target but does not expose the persisted returned object from `CommandLogEntry#getResult()` in the exported data.
-Including the returned object makes exported commands easier to inspect, correlate, and replay-aware tooling can reason about action results without querying the original command log entry.
-
-## What Changes
-
-- Extend exported command YAML to include a returned object entry for each command when `CommandLogEntry#getResult()` is present.
-- Represent the returned object with the same bookmark shape used for the target: `logicalTypeName` and `id`.
-- Preserve existing export behavior for commands with no returned object by omitting the returned object entry or leaving it null, as appropriate for the existing YAML serialization conventions.
-- Keep import/replay compatibility so existing command import continues to consume the command DTO data required for replay.
-
-## Capabilities
-
-### New Capabilities
-- `command-export-yaml-result`: Exported command YAML records the returned object bookmark alongside existing command information.
-
-### Modified Capabilities
-
-## Impact
-
-- Affected code is expected in the command log replay/export package, especially `CommandExportManager_exportSelected` and supporting DTO/YAML transformation code.
-- Tests should cover YAML output for commands with and without `CommandLogEntry#getResult()`.
-- The generated YAML file structure changes additively, with no breaking change expected for existing command replay imports.
diff --git a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 3ef77f38469..00000000000
--- a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Exported command YAML includes returned object metadata
-The system SHALL include returned object metadata for each exported command whose underlying `CommandLogEntry` has a non-null returned object bookmark.
-The returned object metadata SHALL contain `logicalTypeName` and `id` fields derived from the returned object's bookmark.
-
-#### Scenario: Export command with returned object
-- **WHEN** a command selected for export has a non-null `CommandLogEntry#getResult()` bookmark
-- **THEN** the generated YAML contains returned object metadata for that command with `logicalTypeName` set to the bookmark logical type name and `id` set to the bookmark identifier
-
-#### Scenario: Export command without returned object
-- **WHEN** a command selected for export has a null `CommandLogEntry#getResult()` bookmark
-- **THEN** the generated YAML does not include returned object metadata for that command
-
-### Requirement: Exported command YAML remains replay compatible
-The system SHALL preserve the command DTO data required by command replay import when adding returned object metadata to exported YAML.
-Existing YAML exports that contain only command DTO data MUST remain importable.
-
-#### Scenario: Import legacy command DTO YAML
-- **WHEN** command replay import receives a YAML file using the legacy command DTO-only export shape
-- **THEN** the system imports the command DTOs as before
-
-#### Scenario: Import YAML with returned object metadata
-- **WHEN** command replay import receives a YAML file generated with returned object metadata
-- **THEN** the system imports the command DTOs needed for replay and does not require the returned object metadata to resolve to an object
diff --git a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/tasks.md b/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/tasks.md
deleted file mode 100644
index 2ea888e62fd..00000000000
--- a/openspec/changes/archive/2026-06-04-include-returned-object-in-command-export/tasks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 1. Export Data Shape
-
-- [x] 1.1 Add an export-specific DTO or record that wraps the command DTO and optional returned object metadata.
-- [x] 1.2 Add a bookmark metadata type with `logicalTypeName` and `id` fields derived from a `Bookmark`.
-- [x] 1.3 Ensure returned object metadata is absent when `CommandLogEntry#getResult()` is null.
-
-## 2. YAML Export Integration
-
-- [x] 2.1 Update `CommandExportManager_exportSelected` to serialize wrapped export entries instead of bare command DTOs.
-- [x] 2.2 Preserve existing ordering, filename generation, YAML mime type, and replay state updates.
-- [x] 2.3 Verify exported YAML includes returned object metadata for commands with results and omits it for void commands.
-
-## 3. Import Compatibility
-
-- [x] 3.1 Update YAML import utilities or import action code to accept the new wrapped export shape.
-- [x] 3.2 Keep legacy command DTO-only YAML import behavior unchanged.
-- [x] 3.3 Ensure returned object metadata is treated as informational and is not required for replay execution.
-
-## 4. Tests
-
-- [x] 4.1 Add unit tests for bookmark metadata mapping from returned object bookmarks.
-- [x] 4.2 Add export tests covering commands with and without returned object bookmarks.
-- [x] 4.3 Add import compatibility tests for legacy command DTO YAML and new wrapped YAML.
-- [x] 4.4 Run the relevant commandlog applib test suite or targeted Maven tests.
diff --git a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/.openspec.yaml b/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/design.md b/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/design.md
deleted file mode 100644
index ea62fdb06de..00000000000
--- a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/design.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## Context
-
-Command replay imports can now store the recorded returned object bookmark on the replay `CommandLogEntry`.
-During replay, `CommandExecutorService#executeCommand(...)` returns the actual result bookmark produced by executing the command in the target environment.
-
-Those bookmarks can differ when replay creates a new object or resolves to an environment-specific instance.
-Applications that maintain cross-environment references need a supported SPI to observe the mapping from the recorded bookmark to the actual bookmark.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Introduce a public SPI for replay result mapping notifications.
-- Notify the SPI after successful replay when both recorded and actual result bookmarks are known.
-- Pass bookmarks as bookmark values and avoid resolving domain objects inside the replay infrastructure.
-- Keep replay state handling and existing replay success behavior intact.
-
-**Non-Goals:**
-
-- Do not persist a generic mapping table in the command log extension.
-- Do not transform future replay commands using mappings in this change.
-- Do not require applications to implement the SPI.
-- Do not notify the SPI for failed replay attempts.
-
-## Decisions
-
-- Add an SPI interface in the command log module's applib SPI package.
- The SPI should expose a method such as `onReplayResultMapped(Bookmark recordedResult, Bookmark actualResult, CommandLogEntry commandLogEntry)` or an equivalent event object.
- Alternative considered: publish a domain event, but an SPI is clearer for application services that need deterministic post-replay callbacks.
-
-- Invoke the SPI from `ReplayableCommand` after replay execution succeeds and before or during the existing replay success handling transaction.
- This location already has access to the imported command log entry and the actual bookmark returned by `CommandExecutorService`.
- Alternative considered: hook into `CommandLogEntry` persistence, but that layer cannot distinguish imported recorded results from actual replay results without additional context.
-
-- Only notify when both recorded and actual bookmarks are non-null.
- The mapping is only meaningful when there is a recorded returned object and replay produced an actual returned object.
- Alternative considered: notify for null values as well, but that pushes non-mapping cases onto every application implementation.
-
-- Allow notification when the recorded and actual bookmarks are equal.
- Equality can be useful for auditing and keeps the SPI semantics simple: successful replay produced a known pair.
- Alternative considered: suppress equal pairs, but that hides successful correlation from applications that want a complete replay result stream.
-
-- Inject the available SPI implementations as a list and allow the list to be empty.
- This keeps the extension opt-in for applications and avoids requiring a no-op implementation.
-
-## Risks / Trade-offs
-
-- [Risk] SPI exceptions could interfere with replay success state updates → Catch and record SPI failures as replay failures only if the implementation policy explicitly requires it; otherwise log and keep replay success behavior stable.
-- [Risk] Applications may expect bookmarks to resolve to objects → Document that the SPI receives bookmarks only and object lookup is the application's responsibility.
-- [Risk] Multiple SPI implementations may exist → Invoke all discovered implementations in the order supplied by the framework.
diff --git a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/proposal.md b/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/proposal.md
deleted file mode 100644
index 1896d1623ab..00000000000
--- a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Command replay can legitimately create a different domain object than the object recorded during export/import.
-Applications need an explicit extension point so they can learn that the recorded result bookmark, such as `demoInvoice:1`, now corresponds to the actual replay result bookmark, such as `demoInvoice:2`.
-
-## What Changes
-
-- Add an SPI that is invoked after a successful command replay when both recorded and actual result bookmarks are available.
-- Provide the SPI with the recorded returned object bookmark from the imported `CommandLogEntry` and the actual bookmark returned by replay execution.
-- Invoke the SPI only after replay succeeds, and avoid invoking it for failed replay attempts.
-- Do not require either bookmark to resolve to a live domain object before notifying the SPI.
-
-## Capabilities
-
-### New Capabilities
-
-- `command-replay-result-mapping`: Allows applications to observe mappings from recorded replay result bookmarks to actual replay result bookmarks.
-
-### Modified Capabilities
-
-- None.
-
-## Impact
-
-- Affects command replay success handling in `ReplayableCommand`.
-- Adds a command log replay SPI type for application-provided mapping handlers.
-- Adds module registration for the default/no-op SPI implementation if required.
-- Adds tests for SPI invocation, non-invocation, and bookmark values.
diff --git a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 97ff0ea95cc..00000000000
--- a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay result mapping SPI is notified after successful replay
-The system SHALL provide an SPI that applications can implement to receive replay result bookmark mappings.
-After a command replay succeeds, the system SHALL notify the SPI when the imported command log entry has a recorded returned object bookmark and replay execution returns an actual result bookmark.
-The notification SHALL include the recorded returned object bookmark and the actual replay result bookmark.
-
-#### Scenario: Successful replay produces a different result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **THEN** the system notifies the replay result mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Successful replay produces the same result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:1`
-- **THEN** the system notifies the replay result mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-### Requirement: Replay result mapping SPI is not notified when mapping data is unavailable
-The system MUST NOT notify the replay result mapping SPI unless replay succeeds and both recorded and actual result bookmarks are available.
-
-#### Scenario: Replay fails
-- **WHEN** command replay fails for an imported command whose recorded result bookmark is available
-- **THEN** the system does not notify the replay result mapping SPI
-
-#### Scenario: Recorded result is absent
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is absent
-- **THEN** the system does not notify the replay result mapping SPI
-
-#### Scenario: Actual result is absent
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is available
-- **AND** replay execution does not return an actual result bookmark
-- **THEN** the system does not notify the replay result mapping SPI
-
-### Requirement: Replay result mapping SPI uses bookmarks without resolving objects
-The system SHALL pass recorded and actual result bookmarks to the replay result mapping SPI without requiring those bookmarks to resolve to live domain objects.
-
-#### Scenario: Recorded object is not resolvable
-- **WHEN** command replay succeeds and the recorded result bookmark does not resolve to a local domain object
-- **THEN** the system can still notify the replay result mapping SPI with the recorded bookmark and actual bookmark
diff --git a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/tasks.md b/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/tasks.md
deleted file mode 100644
index 5fe488637da..00000000000
--- a/openspec/changes/archive/2026-06-04-notify-replay-result-mapping/tasks.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## 1. SPI Definition
-
-- [x] 1.1 Add a replay result mapping SPI interface that accepts the recorded result bookmark, actual result bookmark, and replayed `CommandLogEntry` context.
-- [x] 1.2 Add optional listener injection so replay works when applications do not provide an implementation.
-- [x] 1.3 Wire available SPI implementations into the command replay context.
-
-## 2. Replay Integration
-
-- [x] 2.1 Update `ReplayableCommand#tryReplay` success handling to retain the actual replay result bookmark.
-- [x] 2.2 Read the recorded result bookmark from the imported replay `CommandLogEntry`.
-- [x] 2.3 Notify the SPI after successful replay when both recorded and actual result bookmarks are non-null.
-- [x] 2.4 Do not notify the SPI for failed replay attempts, missing recorded bookmarks, or missing actual bookmarks.
-- [x] 2.5 Keep existing replay state and analysis updates unchanged.
-
-## 3. Tests
-
-- [x] 3.1 Add tests that a successful replay with different recorded and actual result bookmarks notifies the SPI with both values.
-- [x] 3.2 Add tests that a successful replay with equal recorded and actual result bookmarks still notifies the SPI.
-- [x] 3.3 Add tests that failed replay attempts do not notify the SPI.
-- [x] 3.4 Add tests that missing recorded or actual result bookmarks do not notify the SPI.
-- [x] 3.5 Run focused command replay tests.
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/.openspec.yaml b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/design.md b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/design.md
deleted file mode 100644
index dfdca535693..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/design.md
+++ /dev/null
@@ -1,70 +0,0 @@
-## Context
-
-The command log applib currently provides a built-in `CommandReplayMappingListenerInMemory` that remembers non-identity replay result mappings in an in-memory `HashMap`.
-The listener also remaps later replay inputs by looking up recorded bookmarks in that map.
-A recently added conflict policy controls whether conflicting mappings throw an exception or are logged and ignored.
-
-This is sufficient for a single JVM replay run, but the mapping state is lost when the listener instance is recreated.
-A persistent implementation needs to follow the existing command log persistence split: abstract applib domain and repository contracts, with concrete JDO and JPA entities and repositories in their respective modules.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add an optional persistent built-in replay mapping listener.
-- Preserve the current in-memory listener as the default storage strategy.
-- Use a configuration property to choose between in-memory and persistent built-in storage.
-- Keep custom `CommandReplayMappingListener` beans authoritative over both built-in implementations.
-- Persist recorded and actual bookmarks as `Bookmark` value type properties.
-- Provide abstract applib entity and repository types plus concrete JDO and JPA implementations.
-- Provide menu access and fallback layout metadata for the persisted mappings.
-- Reuse the existing conflict policy semantics for both built-in listener implementations.
-
-**Non-Goals:**
-
-- Do not change the `CommandReplayMappingListener` SPI.
-- Do not persist equal recorded/actual mappings.
-- Do not resolve bookmarks to live domain objects while recording or remapping.
-- Do not introduce a distributed cache or external storage dependency.
-- Do not change command replay transaction boundaries.
-
-## Decisions
-
-- Add a storage strategy enum near the existing replay result mapping configuration.
- Suggested values are `IN_MEMORY` and `PERSISTENT`, with `IN_MEMORY` as the default.
- This keeps the current listener behavior unchanged unless applications opt in to persistence.
-
-- Keep the existing in-memory listener class as the implementation for `IN_MEMORY`.
- Its bean factory should be guarded by no custom `CommandReplayMappingListener` and by storage strategy `IN_MEMORY`.
- The persistent listener should use the same no-custom-listener guard and a storage strategy `PERSISTENT` guard.
-
-- Introduce an abstract applib entity, for example `CommandReplayResultMapping`, with `Bookmark` fields for the recorded and actual bookmarks.
- Reuse the existing `Bookmark` value type persistence support, as `CommandLogEntry` does for target and result bookmarks.
-
-- Introduce an abstract applib repository, for example `CommandReplayResultMappingRepository`, with operations to find by recorded bookmark, list all mappings, and create or retrieve mappings.
- Concrete JDO and JPA repositories should follow the `CommandLogEntryRepository` pattern and live in the matching persistence modules.
-
-- Implement the persistent listener in applib against the abstract repository.
- `remap(...)` finds a mapping by recorded bookmark and returns the actual bookmark if present.
- `onReplayResultMapped(...)` ignores equal bookmarks, creates the first non-identity mapping, treats repeated identical mappings as idempotent, and delegates conflicts to the configured conflict policy.
-
-- Put the command log menu action in applib so the UI contract is common across persistence technologies.
- The action should delegate to the abstract repository and return all persisted mappings.
- Concrete persistence modules provide the entity implementations that make the returned objects renderable.
-
-- Add a `layout.fallback.xml` for the abstract applib mapping entity following existing command log layout conventions.
- The layout should expose recorded and actual bookmark properties and hide technical persistence details where appropriate.
-
-## Risks / Trade-offs
-
-- Persistent mode requires one of the command log persistence modules to supply the concrete repository.
- Mitigation: condition persistent listener creation on the configured storage strategy and the repository bean being available.
-
-- Uniqueness semantics can differ between JDO and JPA implementations.
- Mitigation: enforce lookup-before-create in the repository/listener and add persistence-specific tests for repeated and conflicting mappings.
-
-- Listing all persisted mappings can become large.
- Mitigation: implement the menu action consistently with existing command log menu patterns and consider repository ordering, but leave paging/filtering out of scope for this change.
-
-- Two built-in listener factories could accidentally both create beans.
- Mitigation: use mutually exclusive storage strategy conditions and tests for `IN_MEMORY`, `PERSISTENT`, and custom listener back-off cases.
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/proposal.md b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/proposal.md
deleted file mode 100644
index 95f4e9ab423..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/proposal.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Why
-
-The current default replay mapping listener can remember result mappings only for the lifetime of a single in-memory listener instance.
-Replay workflows that span JVM restarts, multiple operators, or long-running imported command batches need an optional persistent mapping store while retaining the existing lightweight in-memory mode.
-
-## What Changes
-
-- Add a persistent `CommandReplayMappingListener` implementation backed by command log persistence entities.
-- Store recorded and actual bookmarks as `Bookmark` value types, matching the command log entry result/target mapping style but persisted in the datastore.
-- Add abstract applib domain and repository types for replay result mappings, plus concrete JDO and JPA implementations following the `CommandLogEntry` pattern.
-- Add configuration to select the built-in listener storage strategy, with `IN_MEMORY` preserving the current default and `PERSISTENT` enabling the new persistent implementation.
-- Rework the current default in-memory listener so it is conditionally enabled only when the storage strategy is `IN_MEMORY` and no custom listener exists.
-- Configure the persistent listener so it is enabled only when the storage strategy is `PERSISTENT` and no custom listener exists.
-- Make the persistent listener honor the existing conflict policy for throwing an exception versus logging and continuing.
-- Add a fallback layout XML for the persistent mapping entity.
-- Add a command log menu action to list the persisted replay result mappings.
-
-## Capabilities
-
-### New Capabilities
-- `persistent-command-replay-mapping-listener`: Provides persisted replay result mapping entities, repositories, menu access, and a persistent built-in `CommandReplayMappingListener` implementation.
-
-### Modified Capabilities
-- `default-command-replay-mapping-listener`: Add built-in listener storage selection so the existing in-memory listener and the new persistent listener are mutually exclusive conditional defaults.
-
-## Impact
-
-- Affects command log applib, persistence-jdo, and persistence-jpa modules.
-- Adds new persistence entities, repositories, and layout metadata.
-- Adds or changes command log configuration properties for storage strategy and listener conflict behavior.
-- Updates autoconfiguration tests for in-memory and persistent listener activation.
-- Adds persistence tests for JDO and JPA implementations.
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md
deleted file mode 100644
index c00813a130c..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/default-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Default replay mapping listener uses in-memory state
-When the built-in replay mapping listener storage strategy is `IN_MEMORY`, the default command replay mapping listener SHALL store mappings in memory only.
-The system SHALL NOT require the in-memory listener to persist mappings across JVM restarts, application nodes, or Spring bean lifecycle recreation.
-The system SHALL use `IN_MEMORY` as the default built-in replay mapping listener storage strategy.
-
-#### Scenario: Mapping state is scoped to listener instance
-- **WHEN** the in-memory listener records that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** a new in-memory listener instance is created
-- **THEN** the new listener instance has no required remembered mapping for `demoInvoice:1`
-
-#### Scenario: In-memory listener is the default storage strategy
-- **WHEN** the application does not configure a built-in replay mapping listener storage strategy
-- **THEN** the system uses the in-memory listener as the built-in replay mapping listener
-
-## ADDED Requirements
-
-### Requirement: Built-in in-memory replay mapping listener is conditionally enabled
-When the built-in replay mapping listener storage strategy is `IN_MEMORY` and no application-defined `CommandReplayMappingListener` bean is present, the command log autoconfiguration SHALL provide the in-memory replay mapping listener.
-When an application-defined `CommandReplayMappingListener` bean is present, the command log autoconfiguration MUST NOT provide the in-memory replay mapping listener.
-When the storage strategy is not `IN_MEMORY`, the command log autoconfiguration MUST NOT provide the in-memory replay mapping listener.
-
-#### Scenario: In-memory listener is autoconfigured when selected
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `IN_MEMORY`
-- **AND** the application context contains no custom `CommandReplayMappingListener` bean
-- **THEN** the command log autoconfiguration provides the in-memory replay mapping listener
-
-#### Scenario: In-memory listener backs off for custom listener
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `IN_MEMORY`
-- **AND** the application context contains a custom `CommandReplayMappingListener` bean
-- **THEN** the command log autoconfiguration does not provide the in-memory replay mapping listener
-
-#### Scenario: In-memory listener is not created for persistent storage
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `PERSISTENT`
-- **THEN** the command log autoconfiguration does not provide the in-memory replay mapping listener
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/persistent-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/persistent-command-replay-mapping-listener/spec.md
deleted file mode 100644
index 189ef0b2f8a..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/specs/persistent-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,98 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Persistent replay mapping listener records result mappings
-The system SHALL provide a persistent command replay mapping listener that records non-identity replay result mappings by recorded result bookmark.
-The persisted mapping SHALL store the recorded bookmark and actual bookmark as bookmark value type properties.
-When replay notifies the persistent listener with equal recorded and actual result bookmarks, the listener MUST NOT persist a mapping for that notification.
-When no mapping exists for a recorded result bookmark, the persistent listener SHALL create a mapping to the actual result bookmark.
-When the same recorded bookmark is notified more than once with the same actual bookmark, the persistent listener SHALL treat the notification as idempotent.
-When the same recorded bookmark is notified more than once with a different actual bookmark, the persistent listener SHALL apply the configured conflict policy and MUST NOT replace the persisted actual bookmark.
-
-#### Scenario: Persistent mapping is recorded
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the system persists a mapping with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Equal result mapping is not persisted
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the system persists no mapping for `demoInvoice:1`
-
-#### Scenario: Repeated persistent mapping is idempotent
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the system keeps one persisted mapping from `demoInvoice:1` to `demoInvoice:2`
-- **AND** no exception is thrown
-
-#### Scenario: Persistent mapping conflict is rejected when configured to throw
-- **GIVEN** the replay mapping conflict policy is configured to throw an exception
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the persistent listener throws an exception
-- **AND** the persisted mapping remains from `demoInvoice:1` to `demoInvoice:2`
-
-#### Scenario: Persistent mapping conflict is logged when configured to continue
-- **GIVEN** the replay mapping conflict policy is configured to log and continue
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the persistent listener logs the conflict
-- **AND** no exception is thrown
-- **AND** the persisted mapping remains from `demoInvoice:1` to `demoInvoice:2`
-
-### Requirement: Persistent replay mapping listener remaps from persisted mappings
-The persistent command replay mapping listener SHALL return a persisted actual bookmark when replay asks it to remap a recorded bookmark that has a stored mapping.
-When no persisted mapping exists for the recorded bookmark, the listener SHALL return no replacement.
-The persistent listener SHALL perform remapping without resolving recorded or actual bookmarks to live domain objects.
-
-#### Scenario: Recorded bookmark is remapped from persisted mapping
-- **WHEN** the persistent listener has stored that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** command replay asks the listener to remap recorded bookmark `demoInvoice:1`
-- **THEN** the persistent listener returns replacement bookmark `demoInvoice:2`
-
-#### Scenario: Unmapped recorded bookmark is not replaced
-- **WHEN** the persistent listener has no persisted mapping for bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to remap recorded bookmark `demoInvoice:1`
-- **THEN** the persistent listener returns no replacement
-
-### Requirement: Persistent replay mappings are represented by applib and persistence-specific types
-The system SHALL define an abstract applib replay result mapping entity that exposes recorded and actual bookmark properties.
-The system SHALL define an abstract applib repository for finding, listing, and creating replay result mappings.
-The JDO command log persistence module SHALL provide a concrete replay result mapping entity and repository.
-The JPA command log persistence module SHALL provide a concrete replay result mapping entity and repository.
-
-#### Scenario: JDO module provides persistent mapping types
-- **WHEN** the command log JDO persistence module is active
-- **THEN** the system provides a concrete JDO replay result mapping entity and repository implementing the applib contracts
-
-#### Scenario: JPA module provides persistent mapping types
-- **WHEN** the command log JPA persistence module is active
-- **THEN** the system provides a concrete JPA replay result mapping entity and repository implementing the applib contracts
-
-### Requirement: Persistent replay mapping listener is conditionally enabled
-The system SHALL provide a configuration property that selects the built-in replay mapping listener storage strategy.
-When the storage strategy is `PERSISTENT` and no application-defined `CommandReplayMappingListener` bean is present, the command log autoconfiguration SHALL provide the persistent replay mapping listener if a replay result mapping repository is available.
-When an application-defined `CommandReplayMappingListener` bean is present, the command log autoconfiguration MUST NOT provide the persistent replay mapping listener.
-When the storage strategy is not `PERSISTENT`, the command log autoconfiguration MUST NOT provide the persistent replay mapping listener.
-
-#### Scenario: Persistent listener is autoconfigured when selected
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `PERSISTENT`
-- **AND** the application context contains no custom `CommandReplayMappingListener` bean
-- **AND** a replay result mapping repository bean is available
-- **THEN** the command log autoconfiguration provides the persistent replay mapping listener
-
-#### Scenario: Persistent listener backs off for custom listener
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `PERSISTENT`
-- **AND** the application context contains a custom `CommandReplayMappingListener` bean
-- **THEN** the command log autoconfiguration does not provide the persistent replay mapping listener
-
-#### Scenario: Persistent listener is not created for in-memory storage
-- **GIVEN** the built-in replay mapping listener storage strategy is configured as `IN_MEMORY`
-- **THEN** the command log autoconfiguration does not provide the persistent replay mapping listener
-
-### Requirement: Persistent replay mappings are listable from the command log menu
-The system SHALL provide a command log menu action that lists persisted replay result mappings.
-The system SHALL provide fallback layout metadata for the persisted replay result mapping entity.
-The list action SHALL return persisted mappings using the abstract applib repository.
-
-#### Scenario: User lists persisted replay mappings
-- **WHEN** a user invokes the command log menu action for replay result mappings
-- **THEN** the system returns the persisted replay result mappings
-- **AND** each mapping displays its recorded and actual bookmarks
diff --git a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/tasks.md b/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/tasks.md
deleted file mode 100644
index 5f9613ccb42..00000000000
--- a/openspec/changes/archive/2026-06-04-persistent-command-replay-mapping-listener/tasks.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## 1. Configuration and Conditional Beans
-
-- [x] 1.1 Add a built-in replay mapping listener storage strategy enum with `IN_MEMORY` and `PERSISTENT` values.
-- [x] 1.2 Add the storage strategy property to `CausewayConfiguration` with `IN_MEMORY` as the default.
-- [x] 1.3 Update the existing in-memory listener bean factory so it is created only for `IN_MEMORY`, only when no custom listener exists, and still receives the conflict policy.
-- [x] 1.4 Add tests for in-memory listener autoconfiguration, persistent-storage back-off, and custom listener back-off.
-
-## 2. Applib Persistent Mapping Model
-
-- [x] 2.1 Add an abstract applib replay result mapping entity with recorded and actual bookmark properties.
-- [x] 2.2 Add bookmark conversion helpers on the applib entity for recorded and actual bookmarks.
-- [x] 2.3 Add an abstract applib replay result mapping repository contract for lookup by recorded bookmark, listing all mappings, and creating mappings.
-- [x] 2.4 Add a fallback layout XML for the replay result mapping entity.
-- [x] 2.5 Add a command log menu action that lists persisted replay result mappings through the applib repository.
-
-## 3. Persistent Listener Implementation
-
-- [x] 3.1 Add a persistent `CommandReplayMappingListener` implementation that depends on the applib repository and conflict policy.
-- [x] 3.2 Implement remapping from persisted recorded bookmark mappings without resolving domain objects.
-- [x] 3.3 Implement result mapping persistence for first non-identity mappings.
-- [x] 3.4 Implement idempotent repeated mapping handling.
-- [x] 3.5 Implement conflict handling that throws or logs-and-continues according to the existing conflict policy.
-- [x] 3.6 Add conditional bean creation for the persistent listener when storage strategy is `PERSISTENT`, no custom listener exists, and a repository is available.
-- [x] 3.7 Add tests for persistent listener remapping, recording, idempotency, strict conflicts, lenient conflicts, and conditional bean creation.
-
-## 4. JDO Persistence Implementation
-
-- [x] 4.1 Add a concrete JDO replay result mapping entity following the command log persistence JDO conventions.
-- [x] 4.2 Add a concrete JDO replay result mapping repository implementing the applib repository contract.
-- [x] 4.3 Register the JDO entity and repository with the command log JDO persistence module.
-- [x] 4.4 Add JDO tests for create, find by recorded bookmark, list all, idempotent repeated mapping, and conflict preservation.
-
-## 5. JPA Persistence Implementation
-
-- [x] 5.1 Add a concrete JPA replay result mapping entity following the command log persistence JPA conventions.
-- [x] 5.2 Add a concrete JPA replay result mapping repository implementing the applib repository contract.
-- [x] 5.3 Register the JPA entity and repository with the command log JPA persistence module.
-- [x] 5.4 Add JPA tests for create, find by recorded bookmark, list all, idempotent repeated mapping, and conflict preservation.
-
-## 6. Validation
-
-- [x] 6.1 Run targeted command log applib tests covering both built-in listener implementations and menu action behavior.
-- [x] 6.2 Run targeted command log JDO persistence tests for the new replay result mapping entity and repository.
-- [x] 6.3 Run targeted command log JPA persistence tests for the new replay result mapping entity and repository.
-- [x] 6.4 Run `openspec validate persistent-command-replay-mapping-listener --type change --strict`.
diff --git a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/.openspec.yaml b/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/design.md b/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/design.md
deleted file mode 100644
index 62cbcb0302f..00000000000
--- a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/design.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Context
-
-The command log applib now has a replay mapping SPI that receives recorded-to-actual result bookmark mappings after successful replay.
-Replay still executes the imported `CommandDto` as recorded, so target identifiers and action parameter values remain fixed to the source environment at recording time.
-
-When replay happens later or in another environment, those identifiers may no longer point at the intended objects.
-The same application service that records result mappings is the natural place to answer replay-time remapping questions before the command is executed.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Broaden the replay result mapping SPI into a command replay mapping SPI.
-- Ask the SPI for target identifier remapping before executing a replayed command.
-- Ask the SPI for reference-valued action parameter remapping before executing a replayed action command.
-- Preserve existing recorded-to-actual result mapping notifications after successful replay.
-- Keep replay unchanged when no SPI implementation exists or when the SPI does not provide replacements.
-
-**Non-Goals:**
-
-- Do not introduce a persisted mapping table in the command log extension.
-- Do not infer mappings automatically from object lookup failures.
-- Do not remap property commands unless their DTO representation explicitly exposes parameter-like values through the same supported path.
-- Do not mutate the persisted imported `CommandDto` unless that is already required by existing replay execution semantics.
-
-## Decisions
-
-- Rename the SPI from result-specific naming to command replay mapping naming.
- A name such as `CommandReplayMappingListener` better describes both pre-execution remapping and post-execution result notification.
- Alternative considered: add a second SPI, but splitting related mapping behavior would force applications to coordinate two services.
-
-- Use optional list injection for SPI implementations, matching the existing opt-in behavior.
- Replay proceeds unchanged when the list is empty.
- Alternative considered: require a default implementation, but the repository policy is to avoid a no-op implementation for this SPI.
-
-- Apply remapping to a replay copy of the command DTO before calling `CommandExecutorService#executeCommand(...)`.
- This prevents application-provided remapping from changing the stored imported command record and keeps audit data aligned with the original recording.
- Alternative considered: mutate the persisted DTO, but that would make subsequent inspection lose the originally recorded values.
-
-- Ask for target remapping using bookmark-like values derived from each target OID.
- The SPI should be able to return a replacement bookmark or replacement identifier for the same logical type.
- Alternative considered: pass only raw identifier strings, but bookmarks give applications both logical type and identifier context.
-
-- Ask for action parameter remapping for parameters represented as `ParamDto` entries with `type: "reference"` and a populated `reference` OID.
- The SPI should receive enough context to identify the command, action member, parameter name or index, and current reference bookmark, then return an optional replacement reference bookmark.
- Alternative considered: support every `ParamDto` value shape immediately, but the supplied replay use case is specifically object reference remapping and reference DTOs provide bookmark-like type/id data.
-
-- Preserve existing result mapping notification semantics after successful replay.
- The renamed SPI should continue to be notified only when both recorded and actual result bookmarks are present.
-
-## Risks / Trade-offs
-
-- [Risk] Deep copying `CommandDto` can be error-prone → Use existing schema marshalling or utility support where available, and cover remapped replay command content with tests.
-- [Risk] Parameter DTOs support many value shapes → Limit the first implementation to reference parameters represented by `ParamDto.reference`, and make no-op behavior explicit for non-reference parameters.
-- [Risk] Multiple SPI implementations could return conflicting remaps → Apply implementations in framework-supplied order, passing each replacement to the next implementation.
-- [Risk] SPI exceptions could break replay → Treat remapping SPI exceptions consistently with existing result notification policy, preferably logging and continuing with the current value unless implementation reveals a stronger requirement.
diff --git a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/proposal.md b/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/proposal.md
deleted file mode 100644
index ea605ae604e..00000000000
--- a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-Command recordings can be replayed later against an environment whose object identifiers have moved on since the recording was captured.
-Replay needs an application SPI to remap command targets and action parameters before execution, while still reporting recorded-to-actual result mappings after execution.
-
-## What Changes
-
-- Extend and likely rename the existing replay result mapping SPI so it represents command replay mapping rather than only result notifications.
-- Before executing a replayed command, ask the SPI whether the command target identifier should be remapped.
-- Before executing a replayed action command, ask the SPI whether any reference-valued action parameter should be remapped, for example a parameter represented by `type: "reference"` with a `reference.type` and `reference.id`.
-- Continue notifying the SPI about recorded-to-actual result bookmark mappings after successful replay.
-- Keep replay behavior unchanged when no SPI implementation is registered or when the SPI returns no remapping.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `command-replay-result-mapping`: Extends the replay mapping SPI from result-only notification to bidirectional replay mapping support for target identifiers, reference-valued action parameters, and result bookmarks.
-
-## Impact
-
-- Affects the command log applib SPI introduced for replay result mapping.
-- Affects `ReplayableCommand` or the replay preparation path before `CommandExecutorService#executeCommand(...)` is called.
-- Affects command DTO cloning or mutation logic for replay-time remapping of targets and reference-valued action parameters.
-- Adds tests for target remapping, reference action parameter remapping, no-op behavior, and continued result mapping notification.
diff --git a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 55dc39454b6..00000000000
--- a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,91 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay mapping SPI can remap command targets before execution
-The system SHALL ask the command replay mapping SPI whether each replayed command target bookmark should be remapped before command execution.
-When the SPI provides a replacement target bookmark, the system SHALL execute the replayed command using the replacement target identifier.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded target identifier.
-
-#### Scenario: Target bookmark is remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement target bookmark `demoCustomer:2`
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:2`
-
-#### Scenario: Target bookmark is not remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** no command replay mapping SPI provides a replacement target bookmark
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:1`
-
-### Requirement: Replay mapping SPI can remap reference action parameters before execution
-The system SHALL ask the command replay mapping SPI whether each replayed action parameter represented as `type: "reference"` with a populated `reference` OID should be remapped before command execution.
-When the SPI provides a replacement reference bookmark, the system SHALL execute the replayed command using the replacement parameter reference.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded parameter reference.
-The system MUST leave non-reference action parameters unchanged by this reference remapping flow.
-
-#### Scenario: Reference action parameter is remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** the command replay mapping SPI returns replacement reference bookmark `simple.SimpleObject:2`
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "2"`
-
-#### Scenario: Reference action parameter is not remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** no command replay mapping SPI provides a replacement reference bookmark
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-
-#### Scenario: Non-reference action parameter is not remapped by reference flow
-- **WHEN** command replay is about to execute an action command with a parameter that is not represented as `type: "reference"`
-- **THEN** the system does not ask the reference parameter remapping flow to replace that parameter
-
-### Requirement: Replay input remapping does not mutate recorded command data
-The system SHALL preserve the imported command log entry's recorded command DTO when applying replay-time target or reference parameter remapping.
-Replay input remapping SHALL affect the command DTO supplied to replay execution, not the recorded command DTO retained for audit and inspection.
-
-#### Scenario: Remapped replay preserves recorded command
-- **WHEN** command replay remaps recorded target bookmark `demoCustomer:1` to actual target bookmark `demoCustomer:2`
-- **THEN** the replay execution receives target bookmark `demoCustomer:2`
-- **AND** the imported command log entry still records target bookmark `demoCustomer:1`
-
-## MODIFIED Requirements
-
-### Requirement: Replay result mapping SPI is notified after successful replay
-The system SHALL provide a command replay mapping SPI that applications can implement to receive replay result bookmark mappings and provide replay input remappings.
-After a command replay succeeds, the system SHALL notify the SPI when the imported command log entry has a recorded returned object bookmark and replay execution returns an actual result bookmark.
-The notification SHALL include the recorded returned object bookmark and the actual replay result bookmark.
-
-#### Scenario: Successful replay produces a different result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Successful replay produces the same result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:1`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-### Requirement: Replay result mapping SPI is not notified when mapping data is unavailable
-The system MUST NOT notify the command replay mapping SPI of result mappings unless replay succeeds and both recorded and actual result bookmarks are available.
-Replay input remapping methods MAY still be called before execution even if result mapping data is unavailable.
-
-#### Scenario: Replay fails
-- **WHEN** command replay fails for an imported command whose recorded result bookmark is available
-- **THEN** the system does not notify the command replay mapping SPI of a result mapping
-
-#### Scenario: Recorded result is absent
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is absent
-- **THEN** the system does not notify the command replay mapping SPI of a result mapping
-
-#### Scenario: Actual result is absent
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is available
-- **AND** replay execution does not return an actual result bookmark
-- **THEN** the system does not notify the command replay mapping SPI of a result mapping
-
-### Requirement: Replay result mapping SPI uses bookmarks without resolving objects
-The system SHALL pass recorded and actual result bookmarks to the command replay mapping SPI without requiring those bookmarks to resolve to live domain objects.
-The system SHALL pass target bookmarks to the command replay mapping SPI without requiring those bookmarks to resolve to live domain objects.
-
-#### Scenario: Recorded object is not resolvable
-- **WHEN** command replay succeeds and the recorded result bookmark does not resolve to a local domain object
-- **THEN** the system can still notify the command replay mapping SPI with the recorded bookmark and actual bookmark
-
-#### Scenario: Target object is not resolvable before remapping
-- **WHEN** command replay is about to execute a command whose recorded target bookmark does not resolve to a local domain object
-- **THEN** the system can still ask the command replay mapping SPI for a replacement target bookmark
diff --git a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/tasks.md b/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/tasks.md
deleted file mode 100644
index 7ab22572f2b..00000000000
--- a/openspec/changes/archive/2026-06-04-remap-command-replay-inputs/tasks.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## 1. SPI Refactor
-
-- [x] 1.1 Rename `ReplayResultMappingListener` to a broader command replay mapping SPI name.
-- [x] 1.2 Preserve the existing recorded-to-actual result mapping notification method under the renamed SPI.
-- [x] 1.3 Add a target remapping method that receives the replay command context and recorded target bookmark, and returns an optional replacement target bookmark.
-- [x] 1.4 Add a reference action parameter remapping method that receives the replay command context, parameter context, and current reference bookmark, and returns an optional replacement reference bookmark.
-- [x] 1.5 Update module wiring and replay context references to use the renamed SPI.
-
-## 2. Replay Input Remapping
-
-- [x] 2.1 Add a utility or method to create a replay-time copy of the imported `CommandDto` before applying remaps.
-- [x] 2.2 Apply target bookmark remapping to the replay-time command DTO copy before execution.
-- [x] 2.3 Apply reference action parameter remapping to `ParamDto.reference` values on the replay-time command DTO copy before execution.
-- [x] 2.4 Pass the remapped command DTO copy to `CommandExecutorService#executeCommand(...)`.
-- [x] 2.5 Preserve the stored imported command DTO unchanged after remapping.
-- [x] 2.6 Keep existing result mapping notification behavior after successful replay.
-
-## 3. Tests
-
-- [x] 3.1 Add tests that target bookmark remapping changes the command DTO supplied to replay execution.
-- [x] 3.2 Add tests that missing target remapping leaves replay execution unchanged.
-- [x] 3.3 Add tests that reference action parameter remapping changes the command DTO supplied to replay execution using a `type: "reference"` parameter with `reference.type` and `reference.id`.
-- [x] 3.4 Add tests that missing reference action parameter remapping leaves replay execution unchanged.
-- [x] 3.5 Add tests that remapping does not mutate the command DTO stored on the imported command log entry.
-- [x] 3.6 Update existing result mapping tests for the renamed SPI.
-- [x] 3.7 Run focused command replay tests.
diff --git a/openspec/changes/archive/2026-06-04-rework-command-import-manager/.openspec.yaml b/openspec/changes/archive/2026-06-04-rework-command-import-manager/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-rework-command-import-manager/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-rework-command-import-manager/design.md b/openspec/changes/archive/2026-06-04-rework-command-import-manager/design.md
deleted file mode 100644
index 1b05786eff9..00000000000
--- a/openspec/changes/archive/2026-06-04-rework-command-import-manager/design.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## Context
-
-`CommandExportManager_exportSelected` now exports selected commands as multi-document YAML entries whose root type is `CommandExportDto`.
-Each export entry contains the replayable `CommandDto` plus optional `returnedObject` metadata derived from `CommandLogEntry#getResult()`.
-
-`CommandReplayManager_importCommands` currently delegates YAML decoding to `CommandDtoUtils.fromYaml(...)` and persists only the returned `CommandDto` values through `CommandLogEntryRepository#saveForReplay`.
-The current utility also accepts a YAML list of `CommandDto` values and does not expose returned object metadata to the importer.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Prefer importing multi-document `CommandExportDto` YAML as the canonical export/import format.
-- Preserve compatibility with legacy multi-document `CommandDto` YAML.
-- Store `CommandExportDto.returnedObject` as the persisted `CommandLogEntry` result bookmark when importing exported commands.
-- Remove support for importing a single YAML list of `CommandDto` values.
-
-**Non-Goals:**
-
-- Do not change how command export selects commands or serializes `CommandDto` content.
-- Do not require the returned object bookmark to resolve to a live domain object during import.
-- Do not change command replay execution semantics beyond the imported metadata stored on `CommandLogEntry`.
-
-## Decisions
-
-- Add an import result model that carries each `CommandDto` together with the optional returned object bookmark.
- This keeps parsing concerns in `CommandDtoUtils` while giving `CommandReplayManager_importCommands` enough information to persist the result.
- Alternative considered: encode returned object back into `CommandDto.userData`, but that would blur the new export envelope with legacy command DTO data and make the import path harder to reason about.
-
-- Attempt `CommandExportDto` multi-document parsing before `CommandDto` multi-document parsing.
- This matches the new export shape and prevents a wrapped export document from being accidentally treated as an empty or malformed command DTO.
- Alternative considered: retain the old order and add post-processing, but that would make error handling dependent on Jackson's partial binding behavior.
-
-- Remove list parsing from the command replay import path.
- The supported formats become explicit multi-document streams, which matches the export manager output and avoids ambiguity between list and document-stream formats.
- Alternative considered: keep list support as an undocumented fallback, but the requested behavior explicitly removes that compatibility surface.
-
-- Persist returned object metadata after creating the replay `CommandLogEntry`.
- `CommandLogEntryRepository#saveForReplay` already owns replay entry creation, and the importer can set `CommandLogEntry#setResult(...)` on the returned entity when the parsed export entry includes a returned object.
- Alternative considered: add an overload to the repository that accepts both values; that is reasonable if implementations need stricter encapsulation, but the import action can remain the orchestration point.
-
-## Risks / Trade-offs
-
-- YAML documents that were previously accepted only because they were lists will fail import → document the supported multi-document alternatives and update tests to assert rejection.
-- Parsing order changes can alter error messages for malformed YAML → keep suppressed failures or otherwise surface both attempted formats when neither import path succeeds.
-- Returned object bookmarks might refer to objects absent on the importing system → store the bookmark without resolving it, matching the export metadata contract.
diff --git a/openspec/changes/archive/2026-06-04-rework-command-import-manager/proposal.md b/openspec/changes/archive/2026-06-04-rework-command-import-manager/proposal.md
deleted file mode 100644
index a1ef6289164..00000000000
--- a/openspec/changes/archive/2026-06-04-rework-command-import-manager/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Command replay import currently needs to align with the export format that can carry returned object metadata.
-The import manager should prefer the richer `CommandExportDto` multi-document YAML shape while retaining replay compatibility for the legacy multi-document `CommandDto` shape.
-
-## What Changes
-
-- Import documents containing multiple `CommandExportDto` YAML documents and extract the embedded command DTOs for replay.
-- When importing `CommandExportDto` YAML, persist each export entry's `returnedObject` value as the result bookmark of the corresponding `CommandLogEntry`.
-- If parsing as multiple `CommandExportDto` documents fails, fall back to parsing the same input as multiple `CommandDto` YAML documents.
-- **BREAKING** Remove support for importing a single YAML list of `CommandDto` values.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `command-export-yaml-result`: Command replay import changes to consume `CommandExportDto` multi-document YAML, retain multi-document `CommandDto` fallback, persist returned object metadata on import, and drop list-of-`CommandDto` import support.
-
-## Impact
-
-- Affects command replay import logic in the command import manager.
-- Affects YAML parsing behavior for command import inputs.
-- Affects `CommandLogEntry` creation or update behavior by setting the result bookmark when returned object metadata is present.
-- Affects tests and documentation for supported command replay import formats.
diff --git a/openspec/changes/archive/2026-06-04-rework-command-import-manager/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-04-rework-command-import-manager/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 1299a510392..00000000000
--- a/openspec/changes/archive/2026-06-04-rework-command-import-manager/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Imported command export YAML stores returned object result
-The system SHALL store returned object metadata from each imported `CommandExportDto` as the result bookmark of the corresponding replay `CommandLogEntry`.
-The system MUST NOT require the returned object bookmark to resolve to an existing domain object during import.
-
-#### Scenario: Import command export with returned object
-- **WHEN** command replay import receives a multi-document YAML file containing a `CommandExportDto` whose `returnedObject` has `logicalTypeName` and `id`
-- **THEN** the system persists the embedded command DTO for replay and sets the created `CommandLogEntry` result bookmark from that returned object metadata
-
-#### Scenario: Import command export without returned object
-- **WHEN** command replay import receives a multi-document YAML file containing a `CommandExportDto` without `returnedObject`
-- **THEN** the system persists the embedded command DTO for replay and leaves the created `CommandLogEntry` result bookmark unset
-
-## MODIFIED Requirements
-
-### Requirement: Exported command YAML remains replay compatible
-The system SHALL preserve the command DTO data required by command replay import when adding returned object metadata to exported YAML.
-Command replay import SHALL first attempt to read the input as a multi-document stream of `CommandExportDto` values.
-If that fails, command replay import SHALL fall back to reading the input as a multi-document stream of `CommandDto` values.
-Command replay import MUST NOT support a single YAML list of `CommandDto` values.
-
-#### Scenario: Import legacy multi-document command DTO YAML
-- **WHEN** command replay import receives a YAML file using the legacy multi-document `CommandDto` export shape
-- **THEN** the system imports the command DTOs as before
-
-#### Scenario: Import YAML with returned object metadata
-- **WHEN** command replay import receives a YAML file generated with returned object metadata
-- **THEN** the system imports the command DTOs needed for replay and stores the returned object metadata as the corresponding command log result when present
-
-#### Scenario: Reject command DTO list YAML
-- **WHEN** command replay import receives a YAML file containing a single list of `CommandDto` values
-- **THEN** the system rejects the import instead of importing the list entries
diff --git a/openspec/changes/archive/2026-06-04-rework-command-import-manager/tasks.md b/openspec/changes/archive/2026-06-04-rework-command-import-manager/tasks.md
deleted file mode 100644
index e21063ab5c0..00000000000
--- a/openspec/changes/archive/2026-06-04-rework-command-import-manager/tasks.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## 1. YAML Import Parsing
-
-- [x] 1.1 Add a `CommandDtoUtils` import result type that exposes each parsed `CommandDto` with its optional returned object bookmark.
-- [x] 1.2 Add a command replay import parser that first reads multi-document `CommandExportDto` YAML.
-- [x] 1.3 Add fallback parsing for multi-document `CommandDto` YAML when `CommandExportDto` parsing fails.
-- [x] 1.4 Remove list-of-`CommandDto` parsing from the command replay import path.
-- [x] 1.5 Preserve useful failure details when neither supported multi-document format can be parsed.
-
-## 2. Replay Import Persistence
-
-- [x] 2.1 Update `CommandReplayManager_importCommands` to use the new import result model rather than only `List<CommandDto>`.
-- [x] 2.2 Persist each imported command for replay through `CommandLogEntryRepository#saveForReplay`.
-- [x] 2.3 Set the created `CommandLogEntry` result bookmark from `CommandExportDto.returnedObject` when present.
-- [x] 2.4 Keep baseline movement based on the embedded command DTO timestamps.
-
-## 3. Tests
-
-- [x] 3.1 Add or update tests for importing multi-document `CommandExportDto` YAML with returned object metadata.
-- [x] 3.2 Add or update tests for importing multi-document `CommandExportDto` YAML without returned object metadata.
-- [x] 3.3 Add or update tests for legacy multi-document `CommandDto` YAML fallback.
-- [x] 3.4 Add or update tests that a YAML list of `CommandDto` values is rejected by command replay import.
-- [x] 3.5 Run the focused command DTO and command replay import test suite.
diff --git a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/.openspec.yaml b/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/.openspec.yaml
deleted file mode 100644
index f617bd1867a..00000000000
--- a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-04
diff --git a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/design.md b/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/design.md
deleted file mode 100644
index 13ef1fea710..00000000000
--- a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/design.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## Context
-
-The command replay mapping SPI currently supports replay input remapping through separate callbacks for command targets and reference-valued action parameters.
-Both callbacks ultimately ask the same question: whether a recorded bookmark should be replaced before replay execution.
-The reference-parameter callback also exposes parameter name and index, but that metadata is not required for the intended mapping use case and makes implementations more complex.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Simplify `CommandReplayMappingListener` so target and reference-parameter remapping both call one `remap(CommandLogEntry, Bookmark)` method.
-- Preserve existing replay behavior for target remapping, reference-parameter remapping, stored DTO immutability, and result mapping notification.
-- Keep the listener resilient by continuing to treat remapping exceptions as no-op mappings.
-- Update tests and OpenSpec coverage to describe the simplified SPI contract.
-
-**Non-Goals:**
-
-- Do not add a discriminator for whether a bookmark came from a target or reference parameter.
-- Do not expose parameter name, parameter index, or DTO internals through the remapping SPI.
-- Do not change YAML import/export formats or command DTO structures.
-- Do not change the result mapping notification method.
-
-## Decisions
-
-- Use a single `default Optional<Bookmark> remap(CommandLogEntry commandLogEntry, Bookmark recordedBookmark)` method on `CommandReplayMappingListener`.
-This keeps the SPI focused on bookmark replacement and avoids leaking replay DTO details to implementations.
-The alternative was to keep separate methods or add a context enum, but both preserve distinctions that are not needed for the current use case.
-
-- Call the same listener method from both target and reference-parameter traversal paths.
-This preserves the existing implementation structure while removing duplicated listener callback code.
-The alternative was to merge traversal into one generic DTO visitor, but that would create a larger refactor than needed for an SPI simplification.
-
-- Keep `onReplayResultMapped(...)` unchanged.
-The requested simplification only concerns replay input remapping, and result notification still needs both recorded and actual result bookmarks.
-The alternative was to rename or reshape result notification for symmetry, but that would add unrelated API churn.
-
-- Treat this as a breaking API change for the recently introduced SPI.
-Existing implementors must rename their remapping override and drop parameter-specific arguments.
-The alternative was to leave deprecated bridge methods, but the SPI was introduced recently and the goal is to remove noise rather than preserve it.
-
-## Risks / Trade-offs
-
-- Existing listener implementations that override `remapTarget(...)` or `remapReferenceParameter(...)` will no longer compile.
-Mitigation: document the breaking change in the proposal and update tests to show the replacement override.
-
-- Implementations cannot make remapping decisions based on parameter name or index.
-Mitigation: this is intentional because that information is not required for the desired SPI use case.
-
-- A single method means an implementation cannot distinguish targets from reference parameters through the SPI signature alone.
-Mitigation: callers that need different behavior can use the recorded bookmark and command log entry context, but no dedicated source discriminator will be introduced.
diff --git a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/proposal.md b/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/proposal.md
deleted file mode 100644
index 01a5fb2d4dc..00000000000
--- a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-The recently introduced command replay mapping listener exposes separate target and reference-parameter remapping methods, but callers only need to provide a replacement bookmark for a recorded bookmark.
-The parameter-specific API adds names and indexes that are not required for the intended SPI use and makes implementations noisier than necessary.
-
-## What Changes
-
-- **BREAKING**: Replace the listener's separate target and reference-parameter remapping methods with a single `remap(...)` method used for both command targets and reference parameters.
-- Keep replay result mapping notification behavior unchanged.
-- Keep replay-time input remapping behavior unchanged except for the simplified listener callback shape.
-- Update tests and documentation/specification to describe the single remapping callback.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `command-replay-result-mapping`: Simplify the command replay mapping SPI requirements so target and reference-parameter remapping use one common remapping method.
-
-## Impact
-
-- Affects the command log applib SPI `CommandReplayMappingListener`.
-- Affects replay input remapping implementation in the command log applib replay flow.
-- Affects tests and any application implementations of the recently introduced listener SPI.
diff --git a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 33941e1793e..00000000000
--- a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replay mapping SPI can remap command targets before execution
-The system SHALL ask the command replay mapping SPI's common remap method whether each replayed command target bookmark should be remapped before command execution.
-When the SPI provides a replacement target bookmark, the system SHALL execute the replayed command using the replacement target identifier.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded target identifier.
-The system SHALL use the same remap method for command targets and reference action parameters.
-
-#### Scenario: Target bookmark is remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2` from its common remap method
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:2`
-
-#### Scenario: Target bookmark is not remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** no command replay mapping SPI provides a replacement bookmark from its common remap method
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:1`
-
-### Requirement: Replay mapping SPI can remap reference action parameters before execution
-The system SHALL ask the command replay mapping SPI's common remap method whether each replayed action parameter represented as `type: "reference"` with a populated `reference` OID should be remapped before command execution.
-When the SPI provides a replacement reference bookmark, the system SHALL execute the replayed command using the replacement parameter reference.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded parameter reference.
-The system MUST leave non-reference action parameters unchanged by this reference remapping flow.
-The system MUST NOT require the SPI to receive parameter name or parameter index metadata to remap a reference action parameter.
-
-#### Scenario: Reference action parameter is remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** the command replay mapping SPI returns replacement bookmark `simple.SimpleObject:2` from its common remap method
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "2"`
-
-#### Scenario: Reference action parameter is not remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** no command replay mapping SPI provides a replacement bookmark from its common remap method
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-
-#### Scenario: Non-reference action parameter is not remapped by reference flow
-- **WHEN** command replay is about to execute an action command with a parameter that is not represented as `type: "reference"`
-- **THEN** the system does not ask the command replay mapping SPI's common remap method to replace that parameter
diff --git a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/tasks.md b/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/tasks.md
deleted file mode 100644
index 6fedcf16e40..00000000000
--- a/openspec/changes/archive/2026-06-04-simplify-listener-spi-remap-method/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. SPI Simplification
-
-- [x] 1.1 Replace `CommandReplayMappingListener#remapTarget(...)` and `remapReferenceParameter(...)` with one default `remap(CommandLogEntry, Bookmark)` method.
-- [x] 1.2 Update listener Javadoc to describe common bookmark remapping for targets and reference parameters.
-- [x] 1.3 Keep `onReplayResultMapped(...)` unchanged.
-
-## 2. Replay Remapping Flow
-
-- [x] 2.1 Update target remapping in `ReplayableCommand` to call the listener's common `remap(...)` method.
-- [x] 2.2 Update reference-parameter remapping in `ReplayableCommand` to call the same `remap(...)` method without passing parameter name or index.
-- [x] 2.3 Preserve no-op behavior when no listener returns a replacement or a listener throws.
-- [x] 2.4 Preserve replay-time DTO copy behavior so recorded command data remains unchanged.
-
-## 3. Tests and Verification
-
-- [x] 3.1 Update `ReplayableCommandMappingTest` mocks and verifications for the single remap method.
-- [x] 3.2 Add or update assertions showing target and reference-parameter remapping both use the same SPI method.
-- [x] 3.3 Run the command log applib replay mapping tests.
-- [x] 3.4 Run `openspec validate --all --strict`.
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/.openspec.yaml b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/design.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/design.md
deleted file mode 100644
index 584d458d9dd..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/design.md
+++ /dev/null
@@ -1,81 +0,0 @@
-## Context
-
-Command export and replay are used for regression testing by recording commands on a test instance and replaying them against both the current system version and a newer system version.
-Replay result mapping already lets applications map recorded returned object bookmarks to actual replay result bookmarks, and later replay steps can use that mapping when targets or reference parameters no longer have the same identifiers.
-The missing link is that safe finder actions are normally not command logged, so a recording can show a later command against an object without also recording the safe action that found that object.
-
-The change crosses command publishing, command logging, export, and replay because the framework must capture the finder invocation as a command log entry and then allow the existing export and replay mapping flows to process it.
-The behavior must be opt-in because safe actions can be frequent.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Provide a configuration property that enables command publishing for safe actions.
-- Preserve the default behavior where safe actions are not command logged unless explicitly configured.
-- Reuse the existing `CommandPublishingFacet`, `CommandDto`, `CommandLogEntry#getResult()`, command export YAML, and replay result mapping SPI concepts.
-- Ensure replay can execute the logged safe action command and notify the mapping SPI when recorded and actual result bookmarks are available.
-
-**Non-Goals:**
-
-- Do not log safe actions by default.
-- Do not inspect or constrain the safe action result shape as part of deciding whether to command publish it.
-- Do not add support for replay mapping list-valued results in this change.
-- Do not change command export file format beyond carrying safe action entries through the existing command export shape.
-- Do not require applications to rewrite existing replay mapping listener implementations.
-
-## Decisions
-
-### Decision: Use an opt-in configuration property
-
-The new behavior will be guarded by `causeway.extensions.command-log.safe-action-command-publishing`.
-The default value will be `false` to avoid increasing command log volume or changing production behavior unexpectedly.
-
-Alternative considered: enable safe action command publishing automatically whenever command logging is enabled.
-That was rejected because many applications use safe actions heavily and may not want finder calls in the audit log outside regression recording contexts.
-
-### Decision: Implement through command publishing facets
-
-The implementation will adjust the action command publishing facet factory so safe actions receive a command publishing facet whose enabled state is controlled by the new command log property.
-This keeps command logging on the normal path: action execution prepares the command for publishing when its facet is enabled, and `CommandSubscriberForCommandLog` persists the command on the standard ready/start/completed notifications.
-Explicit `@Action(commandPublishing = DISABLED)` remains a local opt-out, and explicitly enabled actions are not duplicated because they already use the normal enabled facet.
-
-Alternative considered: create command log entries during `CommandSubscriberForCommandLog#onCompleted` for safe actions that were not published earlier.
-That was rejected because it still required special command-log subscriber logic instead of using the existing command publishing facet model.
-
-Alternative considered: force safe action commands through ready/start publishing from `MemberExecutorServiceDefault` after the action result was known.
-That was rejected because it was a bolt-on around the normal logging boundary and duplicated command publishing concerns outside the facet and subscriber pipeline.
-
-### Decision: Do not use result shape for eligibility
-
-The framework will consider safe action semantics and configuration only when deciding whether to command publish through this feature.
-Returned object bookmarks will still be captured when the existing command result handling can capture them, but null, list, scalar, or otherwise non-bookmarkable results do not prevent the command entry from being recorded.
-
-Alternative considered: log only safe actions that return a single domain object.
-That was rejected for this change because result shape may not be available at facet installation time and the command publishing decision belongs before invocation.
-
-### Decision: Keep replay mapping listener contracts unchanged
-
-Replay of safe action entries will use the existing result mapping notification when the recorded entry and replay result both have bookmarks.
-No new listener method is required.
-
-Alternative considered: add a finder-specific replay mapping callback.
-That was rejected because the existing callback already expresses the required mapping from recorded bookmark to actual bookmark.
-
-## Risks / Trade-offs
-
-- Increased command log volume when enabled → Keep the property disabled by default and document that it is intended for regression recording environments.
-- Safe action replay might have side effects in poorly behaved applications → Limit the feature to opt-in regression recording and rely on the existing semantic contract that safe actions do not mutate state.
-- Safe actions without returned object bookmarks will be recorded but cannot contribute result mappings → Preserve them as replayable dotted-line steps and only notify mapping listeners when bookmark data is available.
-- Applications may want selected safe actions excluded → Continue to respect explicit command publishing annotations such as `DISABLED`.
-
-## Migration Plan
-
-No data migration is required.
-Existing applications keep current behavior because the new property defaults to disabled.
-Regression test applications can enable the property in their test configuration before recording command exports.
-Rollback consists of disabling the property and ignoring any previously recorded safe action entries in newly generated recordings.
-
-## Open Questions
-
-- Confirm whether the final property name `causeway.extensions.command-log.safe-action-command-publishing` matches existing Causeway configuration conventions.
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/proposal.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/proposal.md
deleted file mode 100644
index f727e6692e8..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Regression replay needs a complete dotted line through recorded workflows, including the safe finder actions that locate the domain objects later commands operate on.
-Today command logging normally captures only state-changing commands, so replay result remapping cannot learn how a found object in the recording corresponds to the object found during replay.
-
-## What Changes
-
-- Add an opt-in configuration property that enables command publishing for safe actions through the normal command publishing facet model.
-- Treat enabled safe action invocations as command-log entries with command DTO metadata, so they can be exported and replayed alongside state-changing commands.
-- Store returned object bookmark metadata when the safe action result provides one.
-- Keep existing default behavior unchanged when the property is disabled.
-- Preserve existing command export and replay behavior so recorded finder results can feed the replay mapping SPI in the same way as other commands with returned object metadata.
-
-## Capabilities
-
-### New Capabilities
-- `safe-action-command-publishing`: Opt-in command publishing for safe actions, enabling exported regression recordings to include finder steps and any returned object bookmarks that the framework can capture.
-
-### Modified Capabilities
-- `command-export-yaml-result`: Exported command YAML includes returned object metadata for safe action command log entries when a result bookmark is available.
-- `command-replay-result-mapping`: Replay result mapping notifications include replayed safe action entries when both recorded and actual result bookmarks are available.
-
-## Impact
-
-- Affects command publishing facet creation for safe action invocations.
-- Adds framework configuration under the command log settings namespace.
-- Affects command log export and replay regression tests by allowing finder steps to appear in exported command streams.
-- Requires unit and integration tests covering disabled-by-default behavior, enabled safe action logging, explicit command publishing, export metadata, and replay mapping notifications.
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 724b8dfa602..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Exported command YAML includes logged safe action returned object metadata
-The system SHALL export safe action command log entries using the existing command export YAML shape when safe action command publishing created those entries.
-When a logged safe action entry has a non-null returned object bookmark, the exported YAML SHALL include returned object metadata containing the bookmark logical type name and identifier.
-The system SHALL preserve compatibility with existing command replay import for exported safe action entries.
-
-#### Scenario: Export logged safe action command with returned object
-- **GIVEN** safe action command publishing is enabled
-- **AND** a safe action command log entry has result bookmark `demoCustomer:1`
-- **WHEN** the command is selected for export
-- **THEN** the generated YAML contains the embedded command DTO for the safe action invocation
-- **AND** the generated YAML contains returned object metadata with logical type name `demoCustomer` and id `1`
-
-#### Scenario: Export command stream containing safe and state-changing commands
-- **GIVEN** a command export selection contains a logged safe action command followed by a state-changing command that uses the found object
-- **WHEN** the commands are exported
-- **THEN** the generated YAML preserves both command entries in replay order
-- **AND** the safe action entry includes its returned object metadata when available
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 0a7264a080c..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay result mapping includes logged safe action results
-The system SHALL replay imported safe action command log entries as replayable commands when they are present in the imported command stream.
-After a logged safe action replay succeeds, the system SHALL notify the command replay mapping SPI when the imported command log entry has a recorded returned object bookmark and replay execution returns an actual result bookmark.
-The notification SHALL use the existing replay result mapping SPI contract and SHALL include the recorded result bookmark and the actual replay result bookmark.
-The system MUST NOT notify the SPI for a logged safe action replay when either the recorded or actual result bookmark is unavailable.
-
-#### Scenario: Replayed safe action maps recorded result to actual result
-- **GIVEN** an imported safe action command log entry has recorded result bookmark `demoCustomer:1`
-- **WHEN** command replay executes that safe action and obtains actual result bookmark `demoCustomer:2`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoCustomer:1` and actual bookmark `demoCustomer:2`
-
-#### Scenario: Replayed safe action result is unavailable
-- **GIVEN** an imported safe action command log entry has no recorded result bookmark
-- **WHEN** command replay executes that safe action
-- **THEN** the system does not notify the command replay mapping SPI for that action result
-
-### Requirement: Safe action result mappings can remap later replay inputs
-The system SHALL make replay result mappings produced by logged safe action commands available to the same replay input remapping flow used by other replayed commands.
-When a later replayed command target or reference parameter uses a recorded bookmark that was mapped by an earlier safe action replay, the system SHALL allow the command replay mapping SPI to replace that recorded bookmark with the actual replay bookmark.
-
-#### Scenario: Later replay command target is remapped from safe action result
-- **GIVEN** replay of a safe action command mapped recorded bookmark `demoCustomer:1` to actual bookmark `demoCustomer:2`
-- **WHEN** replay is about to execute a later command whose recorded target bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2`
-- **THEN** the system executes the later replayed command against target bookmark `demoCustomer:2`
-
-#### Scenario: Later replay command reference parameter is remapped from safe action result
-- **GIVEN** replay of a safe action command mapped recorded bookmark `demoCustomer:1` to actual bookmark `demoCustomer:2`
-- **WHEN** replay is about to execute a later command whose reference parameter bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2`
-- **THEN** the system executes the later replayed command with reference parameter bookmark `demoCustomer:2`
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/safe-action-command-publishing/spec.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/safe-action-command-publishing/spec.md
deleted file mode 100644
index cc16d8e064d..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/specs/safe-action-command-publishing/spec.md
+++ /dev/null
@@ -1,54 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Safe action command publishing is configurable
-The system SHALL provide a configuration property that enables command publishing for safe action invocations.
-The system SHALL leave this property disabled by default.
-When the property is disabled, safe action invocations MUST retain the existing behavior and MUST NOT be command logged solely because they are safe actions.
-The system SHALL apply this behavior through the command publishing facet model used by normal command logging.
-
-#### Scenario: Safe action command publishing is disabled by default
-- **WHEN** an application does not configure safe action command publishing
-- **AND** a user invokes a safe action
-- **THEN** the system does not create a command log entry solely for that safe action invocation
-
-#### Scenario: Safe action command publishing is enabled by property
-- **GIVEN** safe action command publishing is configured as enabled
-- **WHEN** a user invokes a safe action
-- **THEN** the system creates a command log entry for that safe action invocation through the normal command publishing flow
-
-### Requirement: Logged safe action entries include command DTO and available result bookmark
-When safe action command publishing is enabled, the system SHALL store a command DTO for each eligible safe action invocation.
-When the safe action returns a bookmarkable domain object and the framework captures a returned object bookmark, the system SHALL store that returned object's bookmark as the command log entry result.
-When the safe action result does not produce a returned object bookmark, the system SHALL still store the safe action command log entry without a result bookmark.
-The command log entry SHALL be suitable for command export and command replay.
-
-#### Scenario: Safe action returns one bookmarkable object
-- **GIVEN** safe action command publishing is enabled
-- **WHEN** a user invokes a safe action with command target and parameters that returns bookmark `demoCustomer:1`
-- **THEN** the system creates a command log entry containing a command DTO for that invocation
-- **AND** the command log entry result is bookmark `demoCustomer:1`
-
-#### Scenario: Safe action returns a result without a bookmark
-- **GIVEN** safe action command publishing is enabled
-- **WHEN** a user invokes a safe action whose result does not produce a returned object bookmark
-- **THEN** the system creates a command log entry containing a command DTO for that invocation
-- **AND** the command log entry has no result bookmark
-
-### Requirement: Safe action command publishing does not affect state-changing action policy
-When safe action command publishing is enabled, the system MUST NOT use this property to determine whether idempotent or non-idempotent actions are command logged.
-Idempotent and non-idempotent actions SHALL continue to use existing command publishing behavior.
-
-#### Scenario: State-changing action is invoked
-- **GIVEN** safe action command publishing is enabled
-- **WHEN** a user invokes an idempotent or non-idempotent action
-- **THEN** the safe action command publishing property does not determine whether the action is command logged
-- **AND** the action continues to follow existing command publishing rules
-
-### Requirement: Explicit command publishing is not duplicated
-When an action invocation is already command logged through existing command publishing rules, the system MUST NOT create a duplicate command log entry for the same invocation through safe action command publishing.
-
-#### Scenario: Safe action is explicitly command-published
-- **GIVEN** safe action command publishing is enabled
-- **AND** a safe action is explicitly configured for command publishing
-- **WHEN** a user invokes that action
-- **THEN** the system stores at most one command log entry for that invocation
diff --git a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/tasks.md b/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/tasks.md
deleted file mode 100644
index 64521a79f39..00000000000
--- a/openspec/changes/archive/2026-06-05-log-safe-single-result-finders/tasks.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## 1. Discovery and Configuration
-
-- [x] 1.1 Locate the existing command publishing, command DTO creation, and command log subscriber paths for action invocations.
-- [x] 1.2 Identify the existing Causeway configuration namespace that should own the safe action command publishing property.
-- [x] 1.3 Add the disabled-by-default boolean configuration property and bind it into the relevant runtime service or subscriber.
-- [x] 1.4 Add documentation metadata or configuration property descriptors if this repository maintains generated config docs.
-
-## 2. Safe Finder Eligibility
-
-- [x] 2.1 Implement command publishing facet eligibility for safe action invocations when the new property is enabled.
-- [x] 2.2 Avoid using result shape as part of safe action command publishing eligibility.
-- [x] 2.3 Allow null, list, collection, array, void, scalar, and otherwise non-bookmarkable results to be command logged when the safe action publishing property is enabled.
-- [x] 2.4 Ensure idempotent and non-idempotent actions continue to follow existing command publishing behavior rather than the safe action command publishing property.
-- [x] 2.5 Prevent duplicate command log entries when a safe action is already explicitly command-published.
-
-## 3. Command Log Entry Creation
-
-- [x] 3.1 Create or adapt the command DTO for eligible safe action invocations so it can be persisted and replayed.
-- [x] 3.2 Persist an eligible safe action invocation as a command log entry when the property is enabled.
-- [x] 3.3 Store the returned object's bookmark as the command log entry result when available.
-- [x] 3.4 Keep disabled-by-default behavior unchanged for safe actions when the property is absent or false.
-
-## 4. Export and Replay Integration
-
-- [x] 4.1 Verify command export includes logged safe finder entries in replay order.
-- [x] 4.2 Verify exported safe finder entries include returned object metadata when a result bookmark is present.
-- [x] 4.3 Verify replay executes imported safe action command entries.
-- [x] 4.4 Verify replay result mapping notifications are emitted for safe finder entries with recorded and actual result bookmarks.
-- [x] 4.5 Verify later replay command targets and reference parameters can be remapped using mappings learned from safe finder replay results.
-
-## 5. Tests and Documentation
-
-- [x] 5.1 Add unit tests for the new configuration property default and enabled values.
-- [x] 5.2 Add tests for safe action command publishing eligibility and result shapes without exclusion.
-- [x] 5.3 Add tests ensuring explicitly command-published safe actions are not duplicated.
-- [x] 5.4 Add export tests covering safe action command entries and returned object metadata.
-- [x] 5.5 Add replay tests covering finder result mapping notifications and subsequent input remapping.
-- [x] 5.6 Update user-facing documentation for regression recording usage and the new configuration property.
-
-## 6. Validation
-
-- [x] 6.1 Run the relevant commandlog applib unit tests.
-- [x] 6.2 Run the relevant commandlog persistence integration tests for JDO and JPA if affected.
-- [x] 6.3 Run OpenSpec validation for `log-safe-single-result-finders`.
diff --git a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/.openspec.yaml b/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/design.md b/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/design.md
deleted file mode 100644
index 001ad46fa62..00000000000
--- a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/design.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are generated in the metamodel when the command-log extension opt-in is enabled.
-The current parameter generation uses each child scalar property as an optional equality filter.
-That is useful for ordinary scalar fields, but blob and clob properties can be large and expensive to compare.
-Technical properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` are also poor user-facing filters and should not appear in selector action prompts or command DTO parameters.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Keep the existing parent selector parameter unchanged.
-- Continue exposing ordinary scalar child properties as optional selector filters.
-- Exclude blob and clob value properties from selector filters before parameter types and names are derived.
-- Exclude child properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` from selector filters before parameter types and names are derived.
-- Ensure validation and invocation receive the same filtered property list used to define the action signature.
-
-**Non-Goals:**
-
-- Do not change selector action ids, names, layout association, or enablement configuration.
-- Do not change ordinary collection rendering or direct row navigation.
-- Do not add command export or replay result-mapping behavior.
-- Do not attempt to infer uniqueness or indexing quality for arbitrary scalar values.
-
-## Decisions
-
-- Add a single selector-parameter eligibility predicate alongside `scalarPropertiesOf`.
- This keeps parameter generation, matching, validation, and invocation aligned because all downstream code already consumes the same `Can<ObjectAssociation>`.
- The alternative was to filter only at DTO or viewer rendering time, but that would leave hidden parameters in the action signature and could still perform expensive matching.
-
-- Treat blob and clob exclusion as value-type based rather than annotation based.
- This targets the actual large value semantics regardless of how the property is declared.
- The alternative was to check names or annotations, but that would be less reliable and could miss framework-provided blob or clob value types.
-
-- Treat `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` exclusion as exact property-id based.
- This matches the metamodel identifiers used for generated action parameter names and avoids changing similarly named business properties such as `externalId` or `versionLabel`.
- The alternative was a broader substring or case-insensitive rule, but that could remove legitimate domain filters unexpectedly.
-
-## Risks / Trade-offs
-
-- Existing recorded selector commands that include newly excluded parameters may no longer match the generated action signature after the change.
- Mitigation: the selector action feature is still opt-in and recent, and the removed parameters were not intended to be stable user-facing filters.
-
-- A domain model may have a business property exactly named `id` or `version` that would otherwise be useful for selection.
- Mitigation: the requirement intentionally favors removing technical metadata from synthetic prompts, and other business scalar fields remain available.
-
-- Blob or clob detection depends on metamodel value-type information being available during selector action creation.
- Mitigation: use the same element type metadata already required for scalar parameter generation and cover the behavior with focused metamodel tests.
diff --git a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/proposal.md b/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/proposal.md
deleted file mode 100644
index 36d4f0dbcdc..00000000000
--- a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions currently risk exposing child properties that are poor equality filters or internal framework identifiers.
-Blob and clob values are expensive to compare, while `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` are technical metadata that should not be presented as selector action parameters.
-
-## What Changes
-
-- Exclude blob and clob child properties from synthetic selector action parameters.
-- Exclude child properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` from synthetic selector action parameters.
-- Preserve the existing parent parameter and eligible scalar child filter parameters.
-- Keep selector action matching based only on the remaining eligible parameters supplied by the caller.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: refine which child properties are eligible to become synthetic selector action filter parameters.
-
-## Impact
-
-- Affects synthetic selector action parameter generation in the metamodel.
-- Affects command DTO shape for synthetic selector action invocations by removing expensive or technical child filter parameters.
-- Requires focused metamodel tests for blob, clob, and framework metadata property exclusion.
diff --git a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 4ea5a66c4cb..00000000000
--- a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action SHALL define one mandatory parent object parameter.
-The parent parameter SHALL be typed as the collection owner type.
-The parent parameter SHALL default to the current action target.
-The parent parameter SHALL be disabled so it cannot be changed by the user.
-The synthetic selector action SHALL define optional parameters for eligible scalar properties of the collection element type.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections or reference properties.
-The synthetic selector action MUST NOT create selector parameters for blob or clob child properties.
-The synthetic selector action MUST NOT create selector parameters for child properties whose ids are `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`.
-
-#### Scenario: Parent parameter is mandatory
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has a mandatory parameter typed as `Lease`
-
-#### Scenario: Parent parameter defaults to action target
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates defaults for the selector action on a `Lease` target
-- **THEN** the parent parameter default is that `Lease` target
-
-#### Scenario: Parent parameter is disabled
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates parameter usability for the selector action
-- **THEN** the parent parameter is disabled
-
-#### Scenario: Scalar child properties become optional filters
-- **GIVEN** `LeaseItem` has scalar properties suitable for equality matching
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those scalar properties
-
-#### Scenario: Non-scalar child members are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection and a reference property
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the child collection or reference property
-
-#### Scenario: Blob and clob child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has blob and clob properties
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the blob or clob properties
-
-#### Scenario: Technical metadata child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has scalar properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`
diff --git a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/tasks.md b/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/tasks.md
deleted file mode 100644
index 9379e98021e..00000000000
--- a/openspec/changes/archive/2026-06-05-omit-system-and-large-selector-parameters/tasks.md
+++ /dev/null
@@ -1,17 +0,0 @@
-## 1. Selector Parameter Eligibility
-
-- [x] 1.1 Add a selector-parameter eligibility predicate for child scalar properties in `ParentedCollectionSelectorActionUtil`.
-- [x] 1.2 Exclude blob and clob value types from the selector action scalar property list.
-- [x] 1.3 Exclude child property ids `logicalTypeName`, `id`, and `version` from the selector action scalar property list.
-- [x] 1.4 Ensure action parameter type generation, parameter naming, validation, and invocation all consume the filtered property list.
-
-## 2. Test Coverage
-
-- [x] 2.1 Extend `ParentedCollectionSelectorActionUtilTest` with blob and clob child properties and assert no selector parameters are generated for them.
-- [x] 2.2 Extend `ParentedCollectionSelectorActionUtilTest` with `logicalTypeName`, `id`, and `version` child properties and assert no selector parameters are generated for them.
-- [x] 2.3 Assert ordinary scalar child properties remain available as optional selector filters.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused metamodel selector action tests.
-- [x] 3.2 Run `openspec validate omit-system-and-large-selector-parameters --strict`.
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/.openspec.yaml b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/design.md b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/design.md
deleted file mode 100644
index cf99468454f..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/design.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are safe metamodel actions generated at runtime when selector action creation is enabled.
-Safe action command publishing relies on normal command publishing facet metadata to decide whether an invocation should create a command log entry.
-If the synthetic action does not carry the expected command publishing facet, the action can exist and invoke successfully while still being invisible to the command log and therefore unavailable for export.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Ensure synthetic selector actions install command publishing metadata through the same facet model used by normal actions.
-- Ensure selector action command logging remains controlled by the existing safe action command publishing configuration.
-- Ensure a logged selector action entry can be exported by the existing command export pipeline.
-- Add focused coverage that verifies the selector action has command publishing metadata and is exportable once logged.
-
-**Non-Goals:**
-
-- Do not introduce a selector-action-specific command logging path outside the normal action invocation flow.
-- Do not make safe action command publishing enabled by default.
-- Do not change selector action ids, parameters, validation, or invocation matching behavior.
-- Do not change replay result mapping behavior.
-
-## Decisions
-
-- Install or repair the command publishing facet on synthetic selector actions during synthetic action creation.
- This keeps the metamodel contract aligned with normal framework actions and avoids special cases in command logging or export.
- The alternative was to add a command-log special case for selector actions, but that would bypass the facet model and increase the chance of duplicate or inconsistent logging.
-
-- Reuse the existing safe action command publishing configuration to decide whether the facet publishes commands.
- This preserves disabled-by-default behavior and means selector actions follow the same policy as other safe actions.
- The alternative was to add a selector-specific publishing property, but selector action creation is already separately opt-in and the command publishing policy should remain centralized.
-
-- Validate export through the presence of a persisted command log entry rather than a separate export hook.
- The export pipeline should not need to know whether a command came from a synthetic or developer-authored safe action.
- The alternative was to add selector-specific export handling, but that would duplicate the existing safe action export behavior.
-
-## Risks / Trade-offs
-
-- The synthetic action may already attempt to install a command publishing facet, so the defect could be caused by facet creation timing or holder metadata rather than a missing line of code.
- Mitigation: inspect the existing facet factory path and add a test that fails on the current observed absence from command logging or export.
-
-- A metamodel-only test can prove the facet is present but not the full export behavior.
- Mitigation: add the lightest integration-style test available for command log creation or command export when safe action publishing is enabled.
-
-- Command logging behavior depends on both selector action creation and safe action command publishing configuration.
- Mitigation: cover both enabled and disabled safe publishing paths so selector actions do not start logging when the safe publishing opt-in is off.
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/proposal.md b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/proposal.md
deleted file mode 100644
index 919ff6a117c..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions are expected to participate in safe action command publishing, but they are not appearing in the command log for export.
-This indicates that the synthetic action metamodel may not be exposing the command publishing metadata needed by the normal command logging and export pipeline.
-
-## What Changes
-
-- Ensure synthetic parented collection selector actions carry the same command publishing facet metadata expected by the safe action command publishing flow.
-- Ensure invoking a synthetic selector action creates a command log entry when safe action command publishing and selector action creation are both enabled.
-- Ensure logged synthetic selector action commands are available to command export with their command DTO and returned object metadata.
-- Preserve disabled-by-default behavior when safe action command publishing is not enabled.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `safe-action-command-publishing`: clarify that synthetic selector actions must expose command publishing facet metadata and create command log entries through the normal flow when enabled.
-- `command-export-yaml-result`: clarify that logged synthetic selector actions are exportable like other logged safe actions.
-
-## Impact
-
-- Affects synthetic selector action metamodel facet installation.
-- Affects command logging behavior for selector action invocations when both relevant opt-in properties are enabled.
-- Affects command export coverage for recorded parent-to-child navigation steps.
-- Requires focused tests proving selector actions have command publishing metadata and can be exported once logged.
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 425e61cad8b..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Exported command YAML includes logged safe action returned object metadata
-The system SHALL export safe action command log entries using the existing command export YAML shape when safe action command publishing created those entries.
-The system SHALL export synthetic parented collection selector action command log entries using the same command export YAML shape as other logged safe action entries.
-When a logged safe action entry has a non-null returned object bookmark, the exported YAML SHALL include returned object metadata containing the bookmark logical type name and identifier.
-The system SHALL preserve compatibility with existing command replay import for exported safe action entries.
-
-#### Scenario: Export logged safe action command with returned object
-- **GIVEN** safe action command publishing is enabled
-- **AND** a safe action command log entry has result bookmark `demoCustomer:1`
-- **WHEN** the command is selected for export
-- **THEN** the generated YAML contains the embedded command DTO for the safe action invocation
-- **AND** the generated YAML contains returned object metadata with logical type name `demoCustomer` and id `1`
-
-#### Scenario: Export logged selector action command with returned object
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is enabled
-- **AND** a synthetic selector action command log entry has result bookmark `demoChild:1`
-- **WHEN** the selector action command is selected for export
-- **THEN** the generated YAML contains the embedded command DTO for the selector action invocation
-- **AND** the generated YAML contains returned object metadata with logical type name `demoChild` and id `1`
-
-#### Scenario: Export command stream containing safe and state-changing commands
-- **GIVEN** a command export selection contains a logged safe action command followed by a state-changing command that uses the found object
-- **WHEN** the commands are exported
-- **THEN** the generated YAML preserves both command entries in replay order
-- **AND** the safe action entry includes its returned object metadata when available
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/safe-action-command-publishing/spec.md b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/safe-action-command-publishing/spec.md
deleted file mode 100644
index a636093801c..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/specs/safe-action-command-publishing/spec.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Synthetic selector actions participate in safe action command publishing
-When synthetic parented collection selector action creation is enabled, the system SHALL treat synthetic parented collection selector actions as safe actions for command publishing purposes.
-The system SHALL expose command publishing facet metadata on synthetic parented collection selector actions using the normal action command publishing facet model.
-When safe action command publishing is disabled, invoking a synthetic selector action MUST NOT create a command log entry solely because it is synthetic.
-When safe action command publishing is enabled and a synthetic selector action is invoked through the normal action invocation flow, the system SHALL create a command log entry through the normal command publishing flow.
-The command log entry for a synthetic selector action SHALL include the command DTO for the selector action invocation.
-When the synthetic selector action returns a bookmarkable child object and the framework captures a returned object bookmark, the command log entry SHALL store that returned object's bookmark as the result.
-
-#### Scenario: Selector action exposes command publishing metadata
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework synthesizes a selector action
-- **THEN** the synthetic selector action exposes command publishing facet metadata through the normal action facet model
-
-#### Scenario: Disabled safe action publishing does not log selector action
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is disabled
-- **WHEN** a synthetic selector action is invoked
-- **THEN** the system does not create a command log entry solely for that invocation
-
-#### Scenario: Enabled safe action publishing logs selector action
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is enabled
-- **WHEN** a synthetic selector action is invoked
-- **THEN** the system creates a command log entry for the selector action invocation through the normal command publishing flow
-- **AND** the command log entry contains the selector action command DTO
-
-#### Scenario: Logged selector action stores returned child bookmark
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is enabled
-- **AND** a synthetic selector action returns bookmark `demoChild:1`
-- **WHEN** the synthetic selector action is invoked through the normal action invocation flow
-- **THEN** the system creates a command log entry for the selector action invocation
-- **AND** the command log entry result is bookmark `demoChild:1`
diff --git a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/tasks.md b/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/tasks.md
deleted file mode 100644
index d939d0420c5..00000000000
--- a/openspec/changes/archive/2026-06-05-publish-selector-actions-for-export/tasks.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## 1. Investigate Existing Command Publishing Path
-
-- [x] 1.1 Inspect how normal safe actions receive `CommandPublishingFacet` metadata.
-- [x] 1.2 Inspect current synthetic selector action facet installation and identify why the command publishing facet is absent or ineffective.
-- [x] 1.3 Identify the lightest command-log or export test fixture that can exercise a synthetic selector action invocation.
-
-## 2. Selector Action Publishing Implementation
-
-- [x] 2.1 Ensure synthetic selector actions expose command publishing facet metadata through the normal action facet model.
-- [x] 2.2 Ensure the facet respects the existing safe action command publishing configuration.
-- [x] 2.3 Ensure no selector action command log entry is created when safe action command publishing is disabled.
-
-## 3. Command Log and Export Coverage
-
-- [x] 3.1 Add focused metamodel coverage that verifies a synthetic selector action has command publishing metadata when safe action publishing is enabled.
-- [x] 3.2 Add coverage that verifies a synthetic selector action invocation creates a command log entry with a selector command DTO when both opt-in properties are enabled.
-- [x] 3.3 Add coverage that verifies a logged synthetic selector action is included by command export with returned object metadata when available.
-
-## 4. Validation
-
-- [x] 4.1 Run the focused selector action and command publishing tests.
-- [x] 4.2 Run `openspec validate publish-selector-actions-for-export --strict`.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/.openspec.yaml b/openspec/changes/archive/2026-06-05-refine-selector-action-layout/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/design.md b/openspec/changes/archive/2026-06-05-refine-selector-action-layout/design.md
deleted file mode 100644
index b33502adff7..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/design.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are built without Java annotations, so their layout metadata must be installed as facets during synthetic action construction.
-Handcrafted actions use `@ActionLayout(associateWith=...)` to produce a `LayoutGroupFacet` and `@ActionLayout(named=...)` to produce a member name facet.
-The synthetic selector action should expose the same effective metamodel contracts without requiring an actual annotated Java method.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Associate each synthetic selector action with the parented collection that it selects from.
-- Give each synthetic selector action the display name `Select`.
-- Use the existing facet contracts consumed by viewers, layout services, and metamodel tooling.
-- Keep the existing synthetic action id and marker metadata unchanged.
-
-**Non-Goals:**
-
-- Do not change selector action invocation, parameters, safe semantics, or config-gated creation.
-- Do not add a domain annotation, mixin, or generated Java method for each selector action.
-- Do not change collection layout XML semantics.
-
-## Decisions
-
-### Install layout association metadata as facets
-
-The implementation should install a `LayoutGroupFacet` on each synthetic selector action whose group id is the parented collection id.
-This mirrors the effective metamodel produced by `@ActionLayout(associateWith="<collectionId>")`.
-The group name can be inferred from the collection id or copied from collection metadata, because consumers primarily use the group id to place the action with its collection peer.
-
-Alternative considered: synthesize an `ActionLayout` annotation instance for the virtual method.
-That would reuse `ActionLayoutFacetFactory`, but it would make the virtual method facade responsible for annotation-proxy behavior that is not otherwise needed.
-Direct facet installation is smaller and matches the existing synthetic action factory approach.
-
-### Install the display name through the member-name facet contract
-
-The implementation should install or replace the synthetic action member-name facet with the static value `Select`.
-This mirrors the effective metamodel produced by `@ActionLayout(named="Select")`.
-The action id remains deterministic and unchanged, so command DTO identity and metamodel lookup continue to use the reserved selector id rather than the display name.
-
-Alternative considered: rename the synthetic action id to `select`.
-That would conflate identity with presentation and could break existing lookup and command DTO behavior.
-
-## Risks / Trade-offs
-
-- Installing layout metadata directly could diverge from future `@ActionLayout` processing changes.
- Mitigation: use the same public facet contracts that layout consumers already read.
-- A fixed `Select` name could be less descriptive than `Select <Child>` in some UIs.
- Mitigation: the collection association provides context, so the shorter name is appropriate when rendered near the collection.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/proposal.md b/openspec/changes/archive/2026-06-05-refine-selector-action-layout/proposal.md
deleted file mode 100644
index f8dd19a13c0..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/proposal.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions are currently distinguishable and invokable, but their layout metadata does not yet mirror a handcrafted action associated with the collection.
-Recording and metamodel tooling should be able to treat the synthetic action like an action declared with `@ActionLayout(associateWith=..., named="Select")`.
-
-## What Changes
-
-- Associate each synthetic selector action with the parented collection that it selects from using the same layout facet model as `@ActionLayout(associateWith=...)`.
-- Name each synthetic selector action `Select` using the same member-name facet model as `@ActionLayout(named="Select")`.
-- Preserve the existing deterministic action id, marker facet, safe semantics, config-gated creation, parameter model, and invocation behavior.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: Synthetic selector actions gain collection association layout metadata and a fixed display name of `Select`.
-
-## Impact
-
-- Affects synthetic action facet installation in `core/metamodel`.
-- Adds or updates metamodel tests for layout group association and display name metadata.
-- Does not change command logging, export, replay, action ids, or selector invocation semantics.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-refine-selector-action-layout/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index e7e5017108b..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the disabled-by-default `causeway.extensions.command-log.parented-collection-selector-actions-enabled` configuration property that enables synthetic parented collection selector action creation.
-When synthetic parented collection selector action creation is enabled, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When synthetic parented collection selector action creation is disabled, the system MUST NOT synthesize parented collection selector actions.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Select` through name metadata equivalent to `@ActionLayout(named="Select")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** synthetic parented collection selector action creation is disabled
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when enabled for a parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Select
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Select`
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/tasks.md b/openspec/changes/archive/2026-06-05-refine-selector-action-layout/tasks.md
deleted file mode 100644
index a2896fdd5bd..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-action-layout/tasks.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## 1. Layout Facets
-
-- [x] 1.1 Identify the existing facet contract consumed for `@ActionLayout(associateWith=...)` and add a synthetic selector facet implementation if needed.
-- [x] 1.2 Install collection association layout metadata on synthetic selector actions using the parented collection id.
-- [x] 1.3 Replace the synthetic selector action display name with `Select` using the member-name facet contract.
-
-## 2. Tests and Validation
-
-- [x] 2.1 Add or update metamodel tests proving selector actions are associated with their parented collection id.
-- [x] 2.2 Add or update metamodel tests proving selector actions have display name `Select` while retaining the deterministic action id.
-- [x] 2.3 Run focused metamodel tests for the synthetic selector action factory.
-- [x] 2.4 Run `openspec validate refine-selector-action-layout --strict` and fix any proposal/spec/task validation issues.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/.openspec.yaml b/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/design.md b/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/design.md
deleted file mode 100644
index cb7d409cf0e..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/design.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions use a mandatory first parameter typed as the collection owner.
-The action is associated with the collection and is intended to be invoked in the context of a parent object, so that first parameter should be populated from the action target and should not be editable.
-Handcrafted actions express equivalent parameter behavior through parameter default facets and disabled facets derived from `default...` and `disableParam...` support methods.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Provide a default value for the synthetic selector action’s first parent parameter using the current action target.
-- Disable the first parent parameter so the user cannot change it in a prompt.
-- Use the existing `ActionParameterDefaultsFacet` and `DisabledFacet` contracts consumed by viewers and metamodel tooling.
-- Keep the parent parameter mandatory and typed as the collection owner.
-
-**Non-Goals:**
-
-- Do not disable scalar child filter parameters.
-- Do not change selector invocation semantics or filtering rules.
-- Do not change action identity, layout association, display name, or command publishing behavior.
-
-## Decisions
-
-### Default the parent parameter from the action target
-
-Install an `ActionParameterDefaultsFacet` on parameter zero that returns the action target from the `ParameterNegotiationModel`.
-This mirrors the effective behavior of a handcrafted default support method while keeping synthetic action construction annotation-free.
-Returning the target also aligns the prompt with invocation semantics, where the collection is read from the supplied parent object.
-
-Alternative considered: rely only on parent choices containing the current target.
-Choices make the target selectable, but they do not pre-populate the prompt and still allow the user to pick a different parent.
-
-### Disable only the parent parameter
-
-Install a `DisabledFacet` on parameter zero with a clear reason that the parent is fixed by the selector action target.
-This mirrors the effective behavior of a handcrafted `disableParam...` support method.
-Scalar child filter parameters remain editable so recordings can provide enough values to identify exactly one child.
-
-Alternative considered: omit the parent parameter entirely and always use the action target internally.
-That would simplify the prompt, but it would change the command DTO parameter shape already established for selector actions.
-
-## Risks / Trade-offs
-
-- Some tooling might have expected all parameters to be editable.
- Mitigation: only parameter zero is disabled, and it represents contextual navigation rather than user-supplied selection criteria.
-- Defaulting from the action target depends on the target being available in the parameter negotiation model.
- Mitigation: selector actions are associated with and invoked against the parent object, and tests should verify the default uses that target.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/proposal.md b/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/proposal.md
deleted file mode 100644
index ee8a2e0c7e3..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/proposal.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## Why
-
-The synthetic selector action’s first parameter represents the collection owner and should be fixed to the current action target.
-If a user or recorder can change that parameter, the action no longer behaves like contextual navigation from the displayed parent collection.
-
-## What Changes
-
-- Ensure the first synthetic selector action parameter defaults to the current action target.
-- Disable the first synthetic selector action parameter using the same facet contract as a handcrafted `disableParam...` support method.
-- Preserve the existing mandatory parent parameter type, selector action id, layout association, display name, scalar filter parameters, and invocation behavior.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: The mandatory parent parameter gains a target default and is disabled so it cannot be changed by the user.
-
-## Impact
-
-- Affects synthetic selector action parameter facet installation in `core/metamodel`.
-- Adds or updates metamodel tests for parent parameter defaults and disabled usability.
-- Does not change command logging, export, replay, action ids, layout metadata, or selector filtering semantics.
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index f7558fb116c..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action SHALL define one mandatory parent object parameter.
-The parent parameter SHALL be typed as the collection owner type.
-The parent parameter SHALL default to the current action target.
-The parent parameter SHALL be disabled so it cannot be changed by the user.
-The synthetic selector action SHALL define optional parameters for eligible scalar properties of the collection element type.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections or reference properties.
-
-#### Scenario: Parent parameter is mandatory
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has a mandatory parameter typed as `Lease`
-
-#### Scenario: Parent parameter defaults to action target
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates defaults for the selector action on a `Lease` target
-- **THEN** the parent parameter default is that `Lease` target
-
-#### Scenario: Parent parameter is disabled
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates parameter usability for the selector action
-- **THEN** the parent parameter is disabled
-
-#### Scenario: Scalar child properties become optional filters
-- **GIVEN** `LeaseItem` has scalar properties suitable for equality matching
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those scalar properties
-
-#### Scenario: Non-scalar child members are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection and a reference property
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the child collection or reference property
diff --git a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/tasks.md b/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/tasks.md
deleted file mode 100644
index c76074511f4..00000000000
--- a/openspec/changes/archive/2026-06-05-refine-selector-parent-parameter/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. Parent Parameter Defaults
-
-- [x] 1.1 Identify the existing parameter default facet contract used by action parameter defaults.
-- [x] 1.2 Add a synthetic default facet for selector parent parameters that returns the current action target.
-- [x] 1.3 Install the parent default facet on parameter zero of synthetic selector actions.
-
-## 2. Parent Parameter Disabled State
-
-- [x] 2.1 Identify the existing disabled facet contract used by disabled action parameters.
-- [x] 2.2 Add a synthetic disabled facet for selector parent parameters with a clear fixed-parent reason.
-- [x] 2.3 Install the disabled facet on parameter zero only, leaving scalar filter parameters editable.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add or update metamodel tests proving the parent parameter has a default.
-- [x] 3.2 Add or update metamodel tests proving the parent parameter default is the current action target.
-- [x] 3.3 Add or update metamodel tests proving the parent parameter is disabled and scalar filter parameters are not disabled by this feature.
-- [x] 3.4 Run focused metamodel tests for the synthetic selector action factory.
-- [x] 3.5 Run `openspec validate refine-selector-parent-parameter --strict` and fix any proposal/spec/task validation issues.
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/.openspec.yaml b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/design.md b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/design.md
deleted file mode 100644
index 1d40cdbb8b6..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/design.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Context
-
-The command-log extension currently exposes `safe-action-command-publishing` to enable safe action command logging and `parented-collection-selector-actions-enabled` to create synthetic selector actions for parented collections.
-Both properties support the same regression recording use case and are expected to be enabled together.
-The project prefers enum-valued configuration over booleans where future modes may be needed.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add `causeway.extensions.command-log.recording-support` as an enum property with values `ENABLED` and `DISABLED`.
-- Default `recording-support` to `DISABLED`.
-- Use `recording-support=ENABLED` to enable both safe action command publishing and synthetic parented collection selector action creation.
-- Remove or stop using the two current boolean configuration properties.
-- Update documentation and tests to describe the unified recording support switch.
-
-**Non-Goals:**
-
-- Do not add additional recording support modes in this change.
-- Do not change command replay mapping configuration.
-- Do not change selector action ids, parameters, matching, validation, invocation, or export behavior except for how the feature is enabled.
-- Do not change command publishing behavior for idempotent or non-idempotent actions.
-
-## Decisions
-
-- Use a `RecordingSupport` enum nested under `CausewayConfiguration.Extensions.CommandLog`.
- This keeps the setting close to the command-log features it controls and makes the external property path `causeway.extensions.command-log.recording-support`.
- The alternative was a boolean replacement, but that would not support future recording modes as cleanly.
-
-- Interpret only `RecordingSupport.ENABLED` as enabling recording support behavior.
- This makes the default `DISABLED` equivalent to both former booleans being false.
- The alternative was to preserve independent toggles for advanced users, but the user-facing intent is one recording mode switch.
-
-- Replace call sites rather than layering compatibility helpers around the old boolean getters.
- This ensures new code and tests depend on the enum property and avoids keeping deprecated boolean semantics alive internally.
- The alternative was to retain the booleans as aliases, but that would make the configuration model less clear and require precedence rules.
-
-## Risks / Trade-offs
-
-- Existing applications using the two boolean properties must migrate to the new enum property.
- Mitigation: document the replacement clearly and keep the new default disabled to avoid accidental behavior changes.
-
-- Some users may have enabled safe action command publishing without selector action creation.
- Mitigation: this change intentionally aligns both under recording support because the current work targets command recording and export.
-
-- Tests and documentation may still refer to the old property names.
- Mitigation: search for both old external property names and old Java accessor names during implementation.
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/proposal.md b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/proposal.md
deleted file mode 100644
index cf901269c12..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/proposal.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## Why
-
-The command-log recording support currently uses two separate boolean properties for related regression recording behavior.
-A single enum property is clearer for users, keeps recording support configuration centralized, and leaves room for future recording modes beyond a binary boolean pair.
-
-## What Changes
-
-- Replace `causeway.extensions.command-log.safe-action-command-publishing` with `causeway.extensions.command-log.recording-support`.
-- Replace `causeway.extensions.command-log.parented-collection-selector-actions-enabled` with the same `recording-support` property.
-- Define `recording-support` as an enum with values `ENABLED` and `DISABLED`.
-- Default `recording-support` to `DISABLED`.
-- When `recording-support` is `ENABLED`, enable safe action command publishing and synthetic parented collection selector action creation.
-- When `recording-support` is `DISABLED`, retain the current disabled-by-default behavior for both features.
-- **BREAKING**: remove or stop using the two boolean command-log properties in favor of the new enum property.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `safe-action-command-publishing`: replace the safe action publishing boolean switch with enum-based command-log recording support.
-- `parented-collection-selector-actions`: replace the selector action creation boolean switch with enum-based command-log recording support.
-
-## Impact
-
-- Affects `CausewayConfiguration.Extensions.CommandLog` configuration shape and generated external configuration keys.
-- Affects metamodel selector action gating.
-- Affects command publishing facet enablement for safe actions.
-- Affects command-log extension documentation.
-- Requires tests to verify `recording-support=DISABLED` disables both behaviors and `recording-support=ENABLED` enables both behaviors.
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 4268aed5e6a..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls command-log recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `ENABLED`, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize parented collection selector actions.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.parented-collection-selector-actions-enabled` boolean property to enable synthetic parented collection selector action creation.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Select` through name metadata equivalent to `@ActionLayout(named="Select")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when recording support is enabled for a parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Select
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Select`
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/safe-action-command-publishing/spec.md b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/safe-action-command-publishing/spec.md
deleted file mode 100644
index 78559aefb4f..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/specs/safe-action-command-publishing/spec.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Safe action command publishing is configurable
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `DISABLED`, safe action invocations MUST retain the existing behavior and MUST NOT be command logged solely because they are safe actions.
-When `recording-support` is `ENABLED`, the system SHALL enable command publishing for safe action invocations.
-The system SHALL apply this behavior through the command publishing facet model used by normal command logging.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.safe-action-command-publishing` boolean property to enable safe action command publishing.
-
-#### Scenario: Safe action command publishing is disabled by default
-- **WHEN** an application does not configure command-log recording support
-- **AND** a user invokes a safe action
-- **THEN** the system does not create a command log entry solely for that safe action invocation
-
-#### Scenario: Safe action command publishing is enabled by recording support
-- **GIVEN** command-log recording support is configured as `ENABLED`
-- **WHEN** a user invokes a safe action
-- **THEN** the system creates a command log entry for that safe action invocation through the normal command publishing flow
-
-### Requirement: Synthetic selector actions participate in safe action command publishing
-When command-log recording support is `ENABLED`, the system SHALL treat synthetic parented collection selector actions as safe actions for command publishing purposes.
-The system SHALL expose command publishing facet metadata on synthetic parented collection selector actions using the normal action command publishing facet model.
-When command-log recording support is `DISABLED`, invoking a synthetic selector action MUST NOT create a command log entry solely because it is synthetic.
-When command-log recording support is `ENABLED` and a synthetic selector action is invoked through the normal action invocation flow, the system SHALL create a command log entry through the normal command publishing flow.
-The command log entry for a synthetic selector action SHALL include the command DTO for the selector action invocation.
-When the synthetic selector action returns a bookmarkable child object and the framework captures a returned object bookmark, the command log entry SHALL store that returned object's bookmark as the result.
-
-#### Scenario: Selector action exposes command publishing metadata
-- **GIVEN** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes a selector action
-- **THEN** the synthetic selector action exposes command publishing facet metadata through the normal action facet model
-
-#### Scenario: Disabled recording support does not log selector action
-- **GIVEN** command-log recording support is `DISABLED`
-- **WHEN** a synthetic selector action is invoked
-- **THEN** the system does not create a command log entry solely for that invocation
-
-#### Scenario: Enabled recording support logs selector action
-- **GIVEN** command-log recording support is `ENABLED`
-- **WHEN** a synthetic selector action is invoked
-- **THEN** the system creates a command log entry for the selector action invocation through the normal command publishing flow
-- **AND** the command log entry contains the selector action command DTO
-
-#### Scenario: Logged selector action stores returned child bookmark
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** a synthetic selector action returns bookmark `demoChild:1`
-- **WHEN** the synthetic selector action is invoked through the normal action invocation flow
-- **THEN** the system creates a command log entry for the selector action invocation
-- **AND** the command log entry result is bookmark `demoChild:1`
diff --git a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/tasks.md b/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/tasks.md
deleted file mode 100644
index 6fad1ce01df..00000000000
--- a/openspec/changes/archive/2026-06-05-replace-recording-flags-with-enum/tasks.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## 1. Configuration Model
-
-- [x] 1.1 Add `RecordingSupport` enum with `ENABLED` and `DISABLED` values under `CausewayConfiguration.Extensions.CommandLog`.
-- [x] 1.2 Add `recordingSupport` configuration property defaulting to `DISABLED`.
-- [x] 1.3 Remove or stop using `safeActionCommandPublishing` and `parentedCollectionSelectorActionsEnabled` boolean configuration properties.
-- [x] 1.4 Update generated configuration documentation to describe `causeway.extensions.command-log.recording-support` and remove the old boolean properties.
-
-## 2. Behavior Wiring
-
-- [x] 2.1 Update safe action command publishing facet logic to enable safe action command publishing when `recording-support=ENABLED`.
-- [x] 2.2 Update parented collection selector action creation gating to synthesize selector actions when `recording-support=ENABLED`.
-- [x] 2.3 Update all tests and helper code that configure the old boolean properties to use `recordingSupport`.
-
-## 3. Test Coverage
-
-- [x] 3.1 Verify default `recording-support=DISABLED` does not publish safe action commands and does not synthesize selector actions.
-- [x] 3.2 Verify `recording-support=ENABLED` publishes safe action commands and synthesizes selector actions.
-- [x] 3.3 Verify selector action command publishing tests use `recording-support=ENABLED` rather than separate booleans.
-
-## 4. Validation
-
-- [x] 4.1 Run focused command-log and selector action tests.
-- [x] 4.2 Run `openspec validate replace-recording-flags-with-enum --strict`.
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/.openspec.yaml b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/design.md b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/design.md
deleted file mode 100644
index a1f614c40bd..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/design.md
+++ /dev/null
@@ -1,81 +0,0 @@
-## Context
-
-`ObjectSpecificationDefault` builds the metamodel for entity types by creating associations from association faceted methods and actions from action faceted methods during full introspection.
-Parented collections already carry enough metadata to know the parent type, collection id, element type, and element scalar properties, but selecting an element from a rendered collection does not currently pass through `ObjectAction` invocation.
-Command recording already knows how to record logged safe action invocations.
-The missing piece is an invokable, safe metamodel member that represents parent-to-child collection navigation.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Generate synthetic actions for parented collections during metamodel introspection only when explicitly enabled by configuration.
-- Make each synthetic action invokable by command recording code using the normal `ObjectAction` path.
-- Use a mandatory parent reference parameter and optional scalar filter parameters to identify a child object within the parented collection.
-- Return a single child object from the synthetic selector invocation.
-- Keep ordinary collection rendering and row-click navigation unchanged when the feature is disabled.
-
-**Non-Goals:**
-
-- Do not replace collection rendering or require end users to use synthetic actions during normal browsing.
-- Do not add command export or replay result mapping behavior for synthetic selector action results.
-- Do not infer arbitrary business identity for non-scalar associations or plural child matches beyond deterministic selection rules.
-
-## Decisions
-
-### Gate synthetic action creation behind configuration
-
-Create synthetic selector actions only when the disabled-by-default `causeway.extensions.command-log.parented-collection-selector-actions-enabled` configuration property is enabled.
-This keeps ordinary applications from seeing additional metamodel members unless they opt in for command recording or replay tooling.
-When enabled, create synthetic selector actions in `ObjectSpecificationDefault` after `replaceAssociations(createAssociations())` has populated declared associations and before the final action list is installed.
-This keeps collection-derived actions close to the metamodel data that defines them and avoids requiring domain developers to add mixins or explicit finder methods.
-The action stream should concatenate declared actions with synthetic actions derived from eligible parented `OneToManyAssociation`s.
-
-Alternative considered: generate mixin classes or require application-level finder methods.
-That would make command recording possible, but it would push framework replay infrastructure concerns into domain applications and would be inconsistent across apps.
-
-### Represent synthetic selectors as internal safe ObjectActions
-
-Each selector should be an `ObjectAction` with safe semantics and an invocation facet that reads the parented collection from the supplied parent object and returns the matching element.
-The action id should be deterministic and namespaced to avoid colliding with developer actions, for example using a reserved prefix plus the collection id.
-The action should carry marker metadata that lets viewers and metamodel export distinguish synthetic recording actions from user-authored actions when the feature is enabled.
-
-Alternative considered: bypass `ObjectAction` and inject command log entries directly from collection row clicks.
-That would record navigation but would not provide a normal command target and parameter model.
-
-### Parameterize by parent plus optional scalar child values
-
-The first parameter should be mandatory and typed as the parent specification.
-Additional parameters should be optional and derived from scalar properties of the child element specification that are suitable for value equality filtering.
-Synthetic selectors should ignore child collections and reference properties as automatic parameters to avoid deep traversal, unstable object identity, and ambiguous command DTO parameter mapping.
-
-Alternative considered: use a single child bookmark parameter.
-That would not model the dotted parent-to-child navigation path through the parented collection.
-
-### Return one selected child or fail deterministically
-
-Invocation should resolve the parent object, access the collection through the existing association facet, filter by supplied scalar values, and return exactly one child when possible.
-If no child matches or multiple children match, invocation should fail with a clear validation or execution error instead of choosing an arbitrary row.
-This makes exported recordings stable and forces the recorder to supply enough scalar values for replay.
-
-Alternative considered: return a list of matching children.
-Returning a list would lose the single dotted path step.
-
-### Integrate through existing safe action command publishing
-
-Synthetic selector actions should be safe actions and should be command logged only when the existing safe action command publishing configuration enables safe action logging or when an equivalent explicit recording path invokes them.
-This keeps the new behavior additive and avoids special cases in command export and replay.
-
-Alternative considered: always command-publish synthetic selector actions.
-That would surprise applications that are not recording replay scripts and would bypass the disabled-by-default policy introduced for safe actions.
-
-## Risks / Trade-offs
-
-- Synthetic action enumeration could affect viewers or tooling that assume every action comes from application code.
- Mitigation: only create synthetic selector actions when the explicit configuration property is enabled, and add marker metadata so tooling can identify them.
-- Scalar filters may not uniquely identify every collection element.
- Mitigation: require exact single-match results and document that recordings must supply enough scalar values.
-- Creating parameters from every scalar child property can produce large action signatures.
- Mitigation: start with eligible scalar properties and allow later refinement through annotations or configuration if needed.
-- The metamodel currently builds actions from `FacetedMethod`s, so synthetic actions may need a small internal action/facet construction path.
- Mitigation: isolate synthetic action creation behind a factory and reuse existing facets where practical.
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/proposal.md b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/proposal.md
deleted file mode 100644
index 3ccb2b08886..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Regression export and replay need a complete dotted path through recorded workflows, including navigation from a parent object into its parented child collections.
-Today selecting a row from a rendered collection is a UI interaction rather than a command, so recordings lose the parent-to-child lookup step that is needed to remap objects during replay.
-
-## What Changes
-
-- Add the disabled-by-default `causeway.extensions.command-log.parented-collection-selector-actions-enabled` configuration property that enables synthetic parented collection selector action creation.
-- Synthesize safe `ObjectAction`s in the metamodel for parented collections only when that configuration property is enabled so a recorder can navigate from a parent object to a child object through an invokable command.
-- Add one mandatory parameter for the parent object and optional scalar parameters that can identify or narrow the child object within the collection.
-- Return the selected collection element as the action result so command recording can identify the child object selected from the parented collection.
-- Preserve existing collection rendering and direct row selection behavior for ordinary UI navigation when synthetic selector action creation is disabled.
-
-## Capabilities
-
-### New Capabilities
-- `parented-collection-selector-actions`: Synthetic metamodel actions for parented collection navigation that make parent-to-child object selection command-recordable.
-
-### Modified Capabilities
-- `safe-action-command-publishing`: Synthetic parented collection selector actions are safe actions and participate in the existing opt-in safe action command publishing flow.
-
-## Impact
-
-- Affects metamodel introspection in `ObjectSpecificationDefault`, where associations and actions are assembled.
-- Adds internal synthetic `ObjectAction` support for collection-derived lookup actions and their parameters.
-- May affect viewers and metamodel export tests that enumerate or invoke actions when the feature is enabled.
-- Requires tests for config-gated action synthesis, parameter shape, invocation semantics, and integration with safe action command publishing.
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 6bec35faf4f..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,92 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the disabled-by-default `causeway.extensions.command-log.parented-collection-selector-actions-enabled` configuration property that enables synthetic parented collection selector action creation.
-When synthetic parented collection selector action creation is enabled, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When synthetic parented collection selector action creation is disabled, the system MUST NOT synthesize parented collection selector actions.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** synthetic parented collection selector action creation is disabled
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when enabled for a parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action SHALL define one mandatory parent object parameter.
-The parent parameter SHALL be typed as the collection owner type.
-The synthetic selector action SHALL define optional parameters for eligible scalar properties of the collection element type.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections or reference properties.
-
-#### Scenario: Parent parameter is mandatory
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has a mandatory parameter typed as `Lease`
-
-#### Scenario: Scalar child properties become optional filters
-- **GIVEN** `LeaseItem` has scalar properties suitable for equality matching
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those scalar properties
-
-#### Scenario: Non-scalar child members are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection and a reference property
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the child collection or reference property
-
-### Requirement: Selector action invocation returns exactly one child object
-The synthetic selector action SHALL access the collection from the supplied parent object.
-The synthetic selector action SHALL filter collection elements using the supplied scalar parameter values.
-The synthetic selector action SHALL return the single matching child object when exactly one child matches.
-The synthetic selector action MUST fail clearly when no child matches or when multiple children match.
-
-#### Scenario: Single child is selected
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** the selector action parameters identify exactly one `LeaseItem`
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that `LeaseItem`
-
-#### Scenario: No child matches
-- **GIVEN** a `Lease` has no `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the invocation fails with a clear no-match error
-
-#### Scenario: Multiple children match
-- **GIVEN** a `Lease` has more than one `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the invocation fails with a clear ambiguous-match error
-
-### Requirement: Disabled selector action creation preserves ordinary navigation
-The system SHALL preserve existing collection rendering and direct row selection behavior when synthetic selector action creation is disabled.
-The system SHALL avoid adding synthetic selector actions to ordinary metamodel action lists unless the configuration property is enabled.
-
-#### Scenario: Ordinary collection browsing is unchanged by default
-- **GIVEN** a user views a parent object page containing a collection
-- **AND** synthetic parented collection selector action creation is disabled
-- **WHEN** the viewer renders the collection
-- **THEN** the user can still navigate by selecting a rendered collection row
-- **AND** the metamodel does not include a synthetic selector action for the collection
-
-#### Scenario: Command recording can include synthetic actions after opt-in
-- **GIVEN** a command recording surface supports synthetic selector actions
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the recorder enumerates actions for navigating a parented collection
-- **THEN** the synthetic selector action is available for recording the parent-to-child navigation step
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/safe-action-command-publishing/spec.md b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/safe-action-command-publishing/spec.md
deleted file mode 100644
index 5cd50d958c9..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/specs/safe-action-command-publishing/spec.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Synthetic selector actions participate in safe action command publishing
-When synthetic parented collection selector action creation is enabled, the system SHALL treat synthetic parented collection selector actions as safe actions for command publishing purposes.
-When safe action command publishing is disabled, invoking a synthetic selector action MUST NOT create a command log entry solely because it is synthetic.
-When safe action command publishing is enabled and a synthetic selector action is invoked through the normal action invocation flow, the system SHALL create a command log entry through the normal command publishing flow.
-
-#### Scenario: Disabled safe action publishing does not log selector action
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is disabled
-- **WHEN** a synthetic parented collection selector action is invoked
-- **THEN** the system does not create a command log entry solely for that invocation
-
-#### Scenario: Enabled safe action publishing logs selector action
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is enabled
-- **WHEN** a synthetic parented collection selector action is invoked
-- **THEN** the system creates a command log entry for the selector action invocation through the normal command publishing flow
-
diff --git a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/tasks.md b/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/tasks.md
deleted file mode 100644
index 120e57378d3..00000000000
--- a/openspec/changes/archive/2026-06-05-synthesize-parented-collection-actions/tasks.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## 1. Metamodel Synthesis
-
-- [x] 1.1 Identify eligible parented collection associations during `ObjectSpecificationDefault` introspection after associations are created.
-- [x] 1.2 Add a factory or helper that creates deterministic synthetic selector action identifiers and marker metadata for eligible collections.
-- [x] 1.3 Implement synthetic `ObjectAction` construction with safe semantics and integration with existing action enumeration.
-- [x] 1.4 Add a disabled-by-default configuration property and create synthetic selector actions only when that property is enabled.
-
-## 2. Parameter Model
-
-- [x] 2.1 Add a mandatory parent object parameter typed as the collection owner specification.
-- [x] 2.2 Derive optional selector parameters from eligible scalar properties of the collection element specification.
-- [x] 2.3 Exclude child collections and reference properties from automatic selector parameters.
-- [x] 2.4 Ensure synthetic parameter metadata is serializable into command DTOs through the normal action invocation path.
-
-## 3. Invocation Semantics
-
-- [x] 3.1 Implement selector invocation by resolving the supplied parent object and reading the parented collection through the existing association facet.
-- [x] 3.2 Filter collection elements using supplied scalar parameter values with deterministic equality semantics.
-- [x] 3.3 Return the single matching child object when exactly one element matches.
-- [x] 3.4 Fail clearly when no elements match or multiple elements match.
-
-## 4. Command Logging Integration
-
-- [x] 4.1 Verify synthetic selector actions participate in existing safe action command publishing only when that publishing path is enabled.
-
-## 5. Tests and Validation
-
-- [x] 5.1 Add metamodel tests for config-gated synthetic selector action creation, deterministic ids, and marker metadata.
-- [x] 5.2 Add parameter tests for mandatory parent parameters, optional scalar child parameters, and excluded non-scalar members.
-- [x] 5.3 Add invocation tests for single match, no match, and ambiguous match outcomes.
-- [x] 5.4 Run focused Maven tests for the metamodel module touched by the implementation.
-- [x] 5.5 Run `openspec validate synthesize-parented-collection-actions --strict` and fix any proposal/spec/task validation issues.
diff --git a/openspec/changes/archive/2026-06-05-validate-selector-single-row/.openspec.yaml b/openspec/changes/archive/2026-06-05-validate-selector-single-row/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-05-validate-selector-single-row/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-05-validate-selector-single-row/design.md b/openspec/changes/archive/2026-06-05-validate-selector-single-row/design.md
deleted file mode 100644
index 6f581210992..00000000000
--- a/openspec/changes/archive/2026-06-05-validate-selector-single-row/design.md
+++ /dev/null
@@ -1,53 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions currently compute matching child rows inside the invocation facet.
-The invocation facet returns the single match and throws an exception when there are no matches or multiple matches.
-
-The requested behavior is to reject non-unique selector inputs before the action is invoked.
-This aligns selector actions with ordinary Causeway action validation, where invalid parameter combinations are exposed through validation advisors rather than deferred to action execution.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add an action validation facet for synthetic parented collection selector actions.
-- Reuse the same matching semantics for validation and invocation so both paths agree on uniqueness.
-- Return clear validation reasons for no-match and ambiguous-match cases.
-- Preserve the existing invocation result for exactly one matching child row.
-- Keep existing selector action ids, parameters, layout association, safe semantics, and command publishing behavior unchanged.
-
-**Non-Goals:**
-
-- Do not change how selector action parameters are synthesized.
-- Do not make scalar selector parameters mandatory.
-- Do not add command export or replay result-mapping behavior.
-- Do not change ordinary collection row navigation.
-
-## Decisions
-
-- Implement validation as an `ActionValidationFacet` installed on each synthetic selector action.
- Alternative considered: keep throwing from `ActionInvocationFacetForParentedCollectionSelector` only.
- Validation is preferred because it prevents invocation and gives viewers and command execution flows a standard invalidity reason.
-
-- Share row matching logic between validation and invocation.
- Alternative considered: duplicate matching in the validation facet.
- A shared helper keeps no-match, ambiguous-match, and exactly-one behavior consistent and reduces drift.
-
-- Keep defensive invocation checks for non-unique matches.
- Alternative considered: assume validation always runs before invocation and remove invocation-time checks.
- Keeping the checks preserves safety for direct metamodel invocation paths and protects against callers that bypass validation.
-
-- Treat missing or empty parent arguments as invalid input.
- Alternative considered: let invocation throw for a missing parent argument.
- Validation should report the missing parent when enough argument context is available because the selector cannot inspect a collection without a parent.
-
-## Risks / Trade-offs
-
-- Validation inspects the collection before invocation, which may duplicate collection traversal when invocation follows immediately.
- The expected selector collection sizes are user-facing collection rows, and correctness is more important than avoiding a second traversal.
-
-- Validation can observe collection state that changes before invocation.
- Defensive invocation checks remain in place so stale validation cannot cause an incorrect child to be returned.
-
-- Error wording may be asserted by tests or surfaced to users.
- Use stable, concise messages that distinguish no match from multiple matches without exposing internal implementation details.
diff --git a/openspec/changes/archive/2026-06-05-validate-selector-single-row/proposal.md b/openspec/changes/archive/2026-06-05-validate-selector-single-row/proposal.md
deleted file mode 100644
index c17a061d25b..00000000000
--- a/openspec/changes/archive/2026-06-05-validate-selector-single-row/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Selector commands currently rely on invocation-time failure when their filter parameters identify no child row or multiple child rows.
-This allows a command action to be invoked even though the selector cannot identify a unique target, so users and replay flows receive the failure too late.
-
-## What Changes
-
-- Add pre-invocation validation for synthetic parented collection selector actions.
-- Prevent selector action invocation when the supplied parent and scalar filter parameters match no rows.
-- Prevent selector action invocation when the supplied parent and scalar filter parameters match more than one row.
-- Preserve successful invocation when the selector parameters identify exactly one collection row.
-- Surface clear validation messages for no-match and ambiguous-match cases.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: Selector actions validate that their parameters identify exactly one child row before invocation is allowed.
-
-## Impact
-
-- Affects synthetic parented collection selector action validation and invocation behavior in the metamodel.
-- Affects tests for `ParentedCollectionSelectorActionFactoryTest` and any related synthetic action validity facets.
-- No public API or dependency changes are expected.
diff --git a/openspec/changes/archive/2026-06-05-validate-selector-single-row/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-05-validate-selector-single-row/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 6219735c80c..00000000000
--- a/openspec/changes/archive/2026-06-05-validate-selector-single-row/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector action invocation returns exactly one child object
-The synthetic selector action SHALL access the collection from the supplied parent object.
-The synthetic selector action SHALL filter collection elements using the supplied scalar parameter values.
-The synthetic selector action SHALL be valid only when the supplied parent and scalar parameter values identify exactly one matching child object.
-The synthetic selector action MUST prevent invocation with a clear no-match validation reason when no child matches.
-The synthetic selector action MUST prevent invocation with a clear ambiguous-match validation reason when multiple children match.
-The synthetic selector action SHALL return the single matching child object when exactly one child matches.
-The synthetic selector action MUST fail clearly if invocation is attempted without prior successful validation and no child matches or multiple children match.
-
-#### Scenario: Single child is valid and selected
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** the selector action parameters identify exactly one `LeaseItem`
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that `LeaseItem`
-
-#### Scenario: No child match prevents invocation
-- **GIVEN** a `Lease` has no `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear no-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Multiple child matches prevent invocation
-- **GIVEN** a `Lease` has more than one `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear ambiguous-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Direct invocation still fails for no child match
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has no `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear no-match error
-
-#### Scenario: Direct invocation still fails for multiple child matches
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has more than one `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear ambiguous-match error
diff --git a/openspec/changes/archive/2026-06-05-validate-selector-single-row/tasks.md b/openspec/changes/archive/2026-06-05-validate-selector-single-row/tasks.md
deleted file mode 100644
index 708c5a715c0..00000000000
--- a/openspec/changes/archive/2026-06-05-validate-selector-single-row/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. Matching and Validation Support
-
-- [x] 1.1 Extract selector row matching into shared helper logic usable by validation and invocation.
-- [x] 1.2 Add an action validation facet for synthetic parented collection selector actions.
-- [x] 1.3 Return clear validation messages when the parent argument is missing, no collection row matches, or multiple collection rows match.
-
-## 2. Synthetic Action Wiring
-
-- [x] 2.1 Install the selector action validation facet when synthetic selector actions are created.
-- [x] 2.2 Keep invocation-time no-match and multiple-match checks as defensive safeguards for callers that bypass validation.
-
-## 3. Tests and Verification
-
-- [x] 3.1 Add tests that validation allows invocation when selector parameters identify exactly one row.
-- [x] 3.2 Add tests that validation rejects no-row matches and prevents invocation.
-- [x] 3.3 Add tests that validation rejects multiple-row matches and prevents invocation.
-- [x] 3.4 Add tests that direct invocation still fails clearly when validation is bypassed for no-row and multiple-row matches.
-- [x] 3.5 Run the focused metamodel test suite for parented collection selector actions.
-- [x] 3.6 Run `openspec validate validate-selector-single-row --strict`.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/.openspec.yaml b/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/.openspec.yaml
deleted file mode 100644
index b4c82a0a957..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-06
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/design.md b/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/design.md
deleted file mode 100644
index 3dbad2a054b..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/design.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are built during metamodel startup in `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil`.
-They currently discover visible child one-to-one associations, keep only value types, and pass that ordered association list through synthetic action creation, validation, and invocation facets.
-That value-type-only rule excludes reference properties even when the programming model has installed facets that make the reference selectable through a bounded list, explicit choices, or autocomplete.
-
-The implementation must remain startup-safe.
-It should continue to use facets already present on the child property or referenced type, and it should not invoke viewer services, table-column SPIs, grid normalization, repositories, or user-specific services while synthesizing actions.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Include child reference properties as optional selector parameters when a selectable-value facet is installed.
-- Keep existing scalar parameter behavior, ordering, naming, optionality, and technical-property exclusions.
-- Match supplied reference parameter values by exact object equality, while preserving partial contains matching for strings.
-- Cover bounded, choices, autocomplete, and unconstrained reference cases with metamodel tests.
-
-**Non-Goals:**
-
-- Do not synthesize selector parameters for arbitrary child collections or unconstrained references.
-- Do not add new configuration properties.
-- Do not change the command DTO shape or export/import schema.
-- Do not call choice or autocomplete providers during selector synthesis.
-
-## Decisions
-
-- Rename the internal concept from `scalarProperties` to a broader `filterProperties` or equivalent.
- This keeps one ordered association list flowing through parameter creation, validation, and invocation while allowing both value properties and selected reference properties.
- Alternative considered: maintain separate scalar and reference lists, but that would complicate parameter index alignment without adding useful behavior.
-
-- Treat a reference property as eligible when it is one-to-one, non-value, non-collection, visible in parented tables, not technically excluded, and has a selectable facet.
- Selectable means the property has a non-fallback `PropertyChoicesFacet` or `PropertyAutoCompleteFacet`, or the referenced type has a non-fallback object-level `ChoicesFacet` from bounded semantics or `AutoCompleteFacet` from domain-object autocomplete semantics.
- Alternative considered: inspect annotations directly, but facet checks are less coupled to annotation sources and match the existing metamodel design.
-
-- Check only for facet presence during synthesis.
- The selector only needs to know that a viewer can present a controlled selector; it must not evaluate choices or autocomplete results during metamodel startup.
- Alternative considered: verify that choices/autocomplete return values, but that could invoke domain code, depend on runtime state, and violate startup safety.
-
-- Keep matching centralized in `ParentedCollectionSelectorMatchingUtil`.
- Strings continue to use contains matching, and all other values, including references, use exact equality after unwrapping managed objects.
- Alternative considered: add specialized bookmark or identity matching for references, but command replay should already reconstruct reference arguments as domain objects before selector matching.
-
-## Risks / Trade-offs
-
-- Reference equality may be sensitive to proxies or detached instances → Use the existing `ManagedObject` unwrapping path and add tests using the same object instances created by the metamodel fixture.
-- Bounded-type and domain-object autocomplete detection use facets installed on the referenced specification rather than the property → Encapsulate selectable-reference eligibility in a helper so the facet lookup can check both the property and element type consistently.
-- More parameters may make selector actions broader than before → Limit references to selectable facets and keep hidden, blob/clob, collection, and technical exclusions.
-- Existing tests and helper names are scalar-specific → Update names carefully while preserving behavior and adding regression coverage for existing scalar cases.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/proposal.md b/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/proposal.md
deleted file mode 100644
index 5b42aafeef0..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/proposal.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions currently only expose scalar child properties as filter parameters.
-This prevents command recording and replay from selecting collection rows by reference properties even when the UI already constrains the reference through bounded, choices, or autocomplete semantics.
-
-## What Changes
-
-- Allow eligible reference properties on collection elements to become optional synthetic selector action parameters when the property is backed by a selectable value facet.
-- Treat the presence of a bounded, choices, or autocomplete facet as sufficient evidence that a reference property can be selected by the user through a dropdown-like interaction.
-- Preserve existing exclusions for child collections, blob or clob properties, technical metadata properties, and reference properties without the required selectable facets.
-- Extend selector matching so supplied reference parameter values identify child rows by exact reference equality.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `parented-collection-selector-actions`: Selector actions can expose selectable reference object child properties as filters, not only value-type child properties.
-
-## Impact
-
-- Affects synthetic selector action parameter discovery in the metamodel.
-- Affects selector validation and invocation matching for reference-typed parameters.
-- Requires tests around bounded, choices, and autocomplete reference properties, plus negative coverage for unconstrained references.
-- Does not add new configuration properties or change the command DTO shape.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 695d943713f..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,178 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action SHALL define one mandatory parent object parameter.
-The parent parameter SHALL be typed as the collection owner type.
-The parent parameter SHALL default to the current action target.
-The parent parameter SHALL be disabled so it cannot be changed by the user.
-The synthetic selector action SHALL define optional parameters for eligible scalar properties of the collection element type that appear as columns of the associated parented collection.
-The synthetic selector action SHALL also define optional parameters for eligible reference properties of the collection element type that appear as columns of the associated parented collection and have a bounded, choices, or autocomplete facet installed.
-A reference property with a bounded referenced type SHALL be considered selectable when the bounded semantics install a non-fallback choices facet for that referenced type.
-A reference property with property choices SHALL be considered selectable when a non-fallback property choices facet is installed on the child property.
-A reference property with property autocomplete SHALL be considered selectable when a non-fallback property autocomplete facet is installed on the child property.
-A reference property with a domain-object autocomplete referenced type SHALL be considered selectable when domain-object autocomplete semantics install a non-fallback autocomplete facet for that referenced type.
-The synthetic selector action SHALL order child filter parameters according to the associated parented collection column order.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections.
-The synthetic selector action MUST NOT automatically create selector parameters for reference properties that do not have a bounded, choices, or autocomplete facet installed.
-The synthetic selector action MUST NOT create selector parameters for blob or clob child properties.
-The synthetic selector action MUST NOT create selector parameters for child properties whose ids are `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`.
-
-#### Scenario: Parent parameter is mandatory
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has a mandatory parameter typed as `Lease`
-
-#### Scenario: Parent parameter defaults to action target
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates defaults for the selector action on a `Lease` target
-- **THEN** the parent parameter default is that `Lease` target
-
-#### Scenario: Parent parameter is disabled
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates parameter usability for the selector action
-- **THEN** the parent parameter is disabled
-
-#### Scenario: Collection column scalar child properties become optional filters
-- **GIVEN** `Lease.items` renders eligible scalar child properties as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those column-backed scalar properties
-
-#### Scenario: Collection column bounded reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the referenced type has bounded semantics that install a choices facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column choices reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the child reference property has a choices facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column autocomplete reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the child reference property has an autocomplete facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column domain-object autocomplete reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the referenced type has domain-object autocomplete semantics that install an autocomplete facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Scalar child properties that are not collection columns are excluded from automatic filters
-- **GIVEN** `LeaseItem` has an eligible scalar property that is not rendered as a column of `Lease.items`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for that non-column scalar property
-
-#### Scenario: Selectable reference child properties that are not collection columns are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a selectable reference property that is not rendered as a column of `Lease.items`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for that non-column reference property
-
-#### Scenario: Child filter parameters follow collection column order
-- **GIVEN** `Lease.items` renders eligible scalar and selectable reference child properties as columns in a configured order
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action lists child filter parameters in the same relative order as the collection columns
-
-#### Scenario: Non-scalar child collections are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection that appears as a collection column
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for the child collection
-
-#### Scenario: Unconstrained reference child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a reference property that appears as a collection column
-- **AND** the reference property has no bounded, choices, or autocomplete facet installed
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for the reference property
-
-#### Scenario: Blob and clob child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has blob and clob properties that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the blob or clob properties
-
-#### Scenario: Technical metadata child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has scalar or reference properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`
-
-### Requirement: Selector action invocation returns exactly one child object
-The synthetic selector action SHALL access the collection from the supplied parent object.
-The synthetic selector action SHALL filter collection elements using the supplied scalar and reference parameter values.
-When a supplied scalar parameter value is a string, the synthetic selector action SHALL match child string property values that contain the supplied string value.
-When a supplied scalar parameter value is not a string, the synthetic selector action SHALL match child property values by exact equality.
-When a supplied reference parameter value is present, the synthetic selector action SHALL match child reference property values by exact equality.
-The synthetic selector action SHALL be valid only when the supplied parent and filter parameter values identify exactly one matching child object.
-The synthetic selector action MUST prevent invocation with a clear no-match validation reason when no child matches.
-The synthetic selector action MUST prevent invocation with a clear ambiguous-match validation reason when multiple children match.
-The synthetic selector action SHALL return the single matching child object when exactly one child matches.
-The synthetic selector action MUST fail clearly if invocation is attempted without prior successful validation and no child matches or multiple children match.
-
-#### Scenario: Single child is valid and selected
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** the selector action parameters identify exactly one `LeaseItem`
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that `LeaseItem`
-
-#### Scenario: Partial string filter identifies a single child
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** exactly one child has a string property value containing the supplied string filter value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that child
-
-#### Scenario: Non-string scalar filters still use exact equality
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** a supplied non-string scalar filter value only partially resembles a child property value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation does not treat the non-string value as a partial match
-
-#### Scenario: Reference filter identifies a single child by exact reference
-- **GIVEN** a `Lease` has several `LeaseItem` children with selectable reference properties
-- **AND** exactly one child refers to the supplied reference parameter value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that child
-
-#### Scenario: Reference filters do not use partial string matching
-- **GIVEN** a `Lease` has several `LeaseItem` children with selectable reference properties
-- **AND** a supplied reference parameter value has the same title text as a different child reference but is not the same referenced object
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation does not match that different child reference by title text
-
-#### Scenario: No child match prevents invocation
-- **GIVEN** a `Lease` has no `LeaseItem` matching the supplied scalar or reference values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear no-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Multiple child matches prevent invocation
-- **GIVEN** a `Lease` has more than one `LeaseItem` matching the supplied scalar or reference values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear ambiguous-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Partial string filter with multiple matches is ambiguous
-- **GIVEN** a `Lease` has more than one `LeaseItem` with string property values containing the supplied string filter value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear ambiguous-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Direct invocation still fails for no child match
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has no `LeaseItem` matching the supplied scalar or reference values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear no-match error
-
-#### Scenario: Direct invocation still fails for multiple child matches
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has more than one `LeaseItem` matching the supplied scalar or reference values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear ambiguous-match error
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/tasks.md b/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/tasks.md
deleted file mode 100644
index 3daae69381c..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-reference-parameters/tasks.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## 1. Parameter Eligibility
-
-- [x] 1.1 Rename selector-action helper variables and constructor arguments from scalar-specific names to filter-property names where they now cover scalar and reference properties.
-- [x] 1.2 Extend child property eligibility so visible one-to-one value properties keep the current behavior.
-- [x] 1.3 Add selectable reference eligibility for child one-to-one non-value properties with a property choices facet, property autocomplete facet, bounded referenced-type choices facet, or referenced-type autocomplete facet.
-- [x] 1.4 Preserve exclusions for child collections, hidden properties, blob and clob values, unconstrained references, and technical metadata property ids.
-
-## 2. Matching and Facet Wiring
-
-- [x] 2.1 Pass the expanded filter-property list through synthetic action parameter type/name creation and action facet installation.
-- [x] 2.2 Pass the expanded filter-property list through validation and invocation facets without changing parent parameter behavior.
-- [x] 2.3 Keep string filter matching as contains matching and verify all non-string values, including references, use exact equality.
-
-## 3. Tests
-
-- [x] 3.1 Add metamodel fixture properties for bounded, property choices, property autocomplete, referenced-type autocomplete, and unconstrained reference cases on selector child rows.
-- [x] 3.2 Verify bounded reference properties become optional selector parameters when visible as collection columns.
-- [x] 3.3 Verify choices reference properties become optional selector parameters when visible as collection columns.
-- [x] 3.4 Verify property autocomplete and referenced-type autocomplete reference properties become optional selector parameters when visible as collection columns.
-- [x] 3.5 Verify unconstrained reference properties and non-column selectable references are excluded.
-- [x] 3.6 Verify selector validation and invocation can identify exactly one child by supplied reference parameter value.
-- [x] 3.7 Verify reference matching does not use title or partial string semantics.
-
-## 4. Validation
-
-- [x] 4.1 Run the focused metamodel selector action test suite.
-- [x] 4.2 Run `openspec validate allow-selector-reference-parameters --strict`.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/.openspec.yaml b/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/.openspec.yaml
deleted file mode 100644
index b4c82a0a957..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-06
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/design.md b/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/design.md
deleted file mode 100644
index 9d19661490a..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/design.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions validate and invoke by filtering the parented collection using provided scalar parameter values.
-The selector must still identify exactly one child object before invocation is valid.
-String-valued child properties are common human-readable filters, and partial text can be sufficient to select a unique child while making recorded navigation commands less brittle.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Use containment matching for provided string filter values.
-- Keep exact equality matching for non-string scalar values.
-- Keep null or absent optional filter parameters ignored as they are today.
-- Keep the existing exactly-one-match contract for validation and invocation.
-- Cover unique, no-match, and ambiguous-match outcomes for partial string matching.
-
-**Non-Goals:**
-
-- Do not change which child properties become selector parameters.
-- Do not change parameter types, names, ordering, mandatory flags, defaults, or disabled state.
-- Do not introduce viewer-specific wildcard syntax or regular expressions.
-- Do not change matching for non-string scalar parameters.
-
-## Decisions
-
-- Implement the behavior in the selector matching predicate used by validation and invocation.
- This keeps validation and direct invocation consistent because both paths depend on the same collection matching semantics.
- The alternative was to special-case validation only, but that would allow direct invocation to behave differently from validated invocation.
-- Treat string matching as simple `contains` semantics when both the supplied filter value and child property value are non-null strings.
- This satisfies the requested partial-match behavior while avoiding more complex wildcard or regex parsing.
- The alternative was prefix matching, but the requested behavior is containment rather than starts-with.
-- Keep matching case sensitivity aligned with Java `String.contains` unless implementation already normalizes values elsewhere.
- This minimizes scope and avoids introducing locale-sensitive behavior.
- The alternative was case-insensitive matching, but that was not requested and can be proposed separately if needed.
-- Preserve exact equality for non-string scalar parameters.
- This avoids surprising behavior for dates, numbers, booleans, enums, and other value types where partial matching is either ambiguous or not meaningful.
-
-## Risks / Trade-offs
-
-- [Risk] A string value that previously matched no child exactly may now match multiple children partially.
- Mitigation: keep the existing ambiguous-match validation and invocation failure behavior.
-- [Risk] Case-sensitive containment may not match all user expectations.
- Mitigation: document and test containment behavior only; defer case-insensitive matching to a separate explicit change if required.
-- [Risk] Matching code duplicated across validation and invocation could drift.
- Mitigation: implement the behavior in the shared matching helper or predicate used by both paths.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/proposal.md b/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/proposal.md
deleted file mode 100644
index 30a81406b1b..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/proposal.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions currently use supplied scalar filter parameter values to identify one matching child object.
-For string filters, exact matching is too strict for command recording and replay scenarios where a partial human-readable value can still identify the intended child clearly.
-
-## What Changes
-
-- Change selector action matching so provided string filter parameter values use `contains` matching rather than exact equality.
-- Keep non-string scalar filter parameters using their existing exact equality matching behavior.
-- Preserve the rule that selector validation and invocation succeed only when the complete set of supplied filters identifies exactly one matching child object.
-- Preserve no-match and ambiguous-match validation behavior when partial string matching identifies zero or multiple child objects.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `parented-collection-selector-actions`: string-valued selector filter parameters match collection element string properties by containment instead of exact equality when a value is provided.
-
-## Impact
-
-- Affected code is expected around selector action validation and invocation filtering in the parented collection selector action facets.
-- Affected tests are expected around selector action validation and invocation for string child property filters.
-- Existing command recordings that used full string values should continue to match because a full value contains itself.
-- Existing recordings that relied on exact-string rejection may now become valid if the partial value uniquely identifies one child.
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 7d3d5df9169..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,64 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector action invocation returns exactly one child object
-The synthetic selector action SHALL access the collection from the supplied parent object.
-The synthetic selector action SHALL filter collection elements using the supplied scalar parameter values.
-When a supplied scalar parameter value is a string, the synthetic selector action SHALL match child string property values that contain the supplied string value.
-When a supplied scalar parameter value is not a string, the synthetic selector action SHALL match child property values by exact equality.
-The synthetic selector action SHALL be valid only when the supplied parent and scalar parameter values identify exactly one matching child object.
-The synthetic selector action MUST prevent invocation with a clear no-match validation reason when no child matches.
-The synthetic selector action MUST prevent invocation with a clear ambiguous-match validation reason when multiple children match.
-The synthetic selector action SHALL return the single matching child object when exactly one child matches.
-The synthetic selector action MUST fail clearly if invocation is attempted without prior successful validation and no child matches or multiple children match.
-
-#### Scenario: Single child is valid and selected
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** the selector action parameters identify exactly one `LeaseItem`
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that `LeaseItem`
-
-#### Scenario: Partial string filter identifies a single child
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** exactly one child has a string property value containing the supplied string filter value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation allows invocation
-- **WHEN** the synthetic selector action is invoked
-- **THEN** the action returns that child
-
-#### Scenario: Non-string scalar filters still use exact equality
-- **GIVEN** a `Lease` has several `LeaseItem` children
-- **AND** a supplied non-string scalar filter value only partially resembles a child property value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation does not treat the non-string value as a partial match
-
-#### Scenario: No child match prevents invocation
-- **GIVEN** a `Lease` has no `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear no-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Multiple child matches prevent invocation
-- **GIVEN** a `Lease` has more than one `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear ambiguous-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Partial string filter with multiple matches is ambiguous
-- **GIVEN** a `Lease` has more than one `LeaseItem` with string property values containing the supplied string filter value
-- **WHEN** the synthetic selector action parameters are validated
-- **THEN** validation rejects the action with a clear ambiguous-match reason
-- **AND** the action is not invoked
-
-#### Scenario: Direct invocation still fails for no child match
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has no `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear no-match error
-
-#### Scenario: Direct invocation still fails for multiple child matches
-- **GIVEN** a caller bypasses validation
-- **AND** a `Lease` has more than one `LeaseItem` matching the supplied scalar values
-- **WHEN** the synthetic selector action is invoked directly
-- **THEN** the invocation fails with a clear ambiguous-match error
diff --git a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/tasks.md b/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/tasks.md
deleted file mode 100644
index 775b17392cb..00000000000
--- a/openspec/changes/archive/2026-06-06-allow-selector-string-partial-match/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Matching Implementation
-
-- [x] 1.1 Update `ParentedCollectionSelectorMatchingUtil` so supplied string filter values match child string property values using containment rather than exact equality.
-- [x] 1.2 Keep non-string scalar filter values using exact equality and keep null or absent optional filter values ignored.
-- [x] 1.3 Verify validation and invocation both use the same updated matching behavior.
-
-## 2. Test Coverage
-
-- [x] 2.1 Add or update selector action tests for a partial string filter that uniquely selects one child.
-- [x] 2.2 Add or update selector action tests for a partial string filter that matches multiple children and remains ambiguous.
-- [x] 2.3 Add or update selector action tests confirming non-string scalar filters still require exact equality.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused selector action test suite for `ParentedCollectionSelectorActionUtilTest`.
-- [x] 3.2 Run `openspec validate allow-selector-string-partial-match --strict`.
diff --git a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/.openspec.yaml b/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/.openspec.yaml
deleted file mode 100644
index c53ef21aaaf..00000000000
--- a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-05
diff --git a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/design.md b/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/design.md
deleted file mode 100644
index e3de1743971..00000000000
--- a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/design.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Context
-
-Parented collection selector actions are synthesized from parented collection associations when command-log recording support is enabled.
-The current implementation builds child filter parameters from every eligible scalar property on the collection element type, then applies generic exclusions for non-scalar, blob, clob, and technical metadata properties.
-Collection rendering already has a column model that determines which element members appear as collection columns and in what order.
-The synthetic selector action should mirror that column model so the prompt matches the row-selection surface it records.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Build synthetic selector child filter parameters from the associated collection's visible columns rather than from every eligible scalar property on the child type.
-- Preserve collection column ordering in the synthetic action parameter order after the mandatory parent parameter.
-- Keep the existing scalar, blob, clob, and technical metadata exclusions as a second filter over the collection columns.
-- Use only static metamodel association metadata that is safe during startup introspection.
-- Preserve startup-safe static layout order by using member `LayoutOrderFacet` sequences where available.
-
-**Non-Goals:**
-
-- Do not change the mandatory disabled parent parameter or its position as the first action parameter.
-- Do not add new configuration properties.
-- Do not change collection rendering, row selection, or command DTO shape beyond the set and order of child filter parameters.
-- Do not make reference, collection, blob, clob, or technical metadata properties eligible merely because they appear as collection columns.
-
-## Decisions
-
-- Derive candidate child filter properties from child associations that are statically visible for `Where.PARENTED_TABLES`.
- This keeps selector prompts aligned with statically rendered collection columns while remaining safe during metamodel startup.
- The alternative was to call `streamAssociationsForColumnRendering`, but that invokes table-column SPIs that can depend on interaction-scoped services and are not safe during application startup.
-
-- Order child filter properties by `LayoutOrderFacet` sequence when present, falling back to member id for deterministic ordering.
- This reuses layout sequence metadata already installed on associations from annotations or XML without normalizing grids during selector synthesis.
- The alternative was to call `GridFacet.getGrid`, but that can recursively trigger selector synthesis while grids are being normalized during startup.
-
-- Apply the existing selector parameter eligibility predicate after resolving the statically column-visible candidates.
- This preserves current safety and size exclusions while allowing static parented-table visibility metadata to control whether scalar properties are candidates.
- The alternative was to trust every rendered column, but rendered columns can include members that should not become equality filter parameters.
-
-- Keep the parent parameter outside the column-derived list.
- The parent parameter represents the selector action target context, not a child column, and existing command export expectations rely on it being present and disabled.
- The alternative was to remove the parent parameter because it is not a collection column, but that would change command DTO structure and parent scoping semantics.
-
-- Add focused metamodel tests around inclusion, omission, and ordering.
- Existing tests already exercise selector parameter generation and are the right place to assert that non-column scalar properties are omitted and column order is preserved.
- The alternative was to rely on viewer tests, but this behavior is synthesized at metamodel level and should be validated without a viewer.
-
-## Risks / Trade-offs
-
-- Runtime column visibility and ordering services can depend on an active interaction, while selector actions are synthesized during metamodel construction.
- Mitigation: do not invoke `TableColumnVisibilityService`, `TableColumnOrderService`, or grid normalization from selector synthesis; use only startup-safe static association visibility and layout-order facets.
-
-- A collection with too few displayed scalar columns may produce an under-specified selector action and increase ambiguous-match validation failures.
- Mitigation: this is consistent with the visible collection shape, and existing validation already rejects ambiguous matches with a clear reason.
-
-- Existing tests or command fixtures may expect parameters for scalar properties that are no longer rendered as collection columns.
- Mitigation: update fixtures and tests to assert the new column-driven contract.
diff --git a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/proposal.md b/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/proposal.md
deleted file mode 100644
index 541b78d654e..00000000000
--- a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Synthetic selector actions currently expose eligible scalar child properties as filter parameters even when those properties are not shown as columns in the parented collection.
-This can make the synthetic action prompt diverge from the collection view that the action represents and can expose parameters users would not otherwise use when selecting a row.
-
-## What Changes
-
-- Limit synthetic selector action child filter parameters to properties that appear as columns of the associated parented collection.
-- Order synthetic selector action child filter parameters according to the collection column order.
-- Preserve the mandatory disabled parent parameter before the child filter parameters.
-- Preserve existing exclusions for non-scalar, blob, clob, and technical metadata child properties.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: synthetic selector action parameter selection and ordering now follow the associated collection columns.
-
-## Impact
-
-- Affects synthetic parented collection selector action parameter discovery in the metamodel.
-- Affects tests covering selector parameter generation and ordering.
-- Does not add new configuration properties, APIs, dependencies, or viewer behavior.
diff --git a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 8227f8e2820..00000000000
--- a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,59 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action SHALL define one mandatory parent object parameter.
-The parent parameter SHALL be typed as the collection owner type.
-The parent parameter SHALL default to the current action target.
-The parent parameter SHALL be disabled so it cannot be changed by the user.
-The synthetic selector action SHALL define optional parameters only for eligible scalar properties of the collection element type that appear as columns of the associated parented collection.
-The synthetic selector action SHALL order child filter parameters according to the associated parented collection column order.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections or reference properties.
-The synthetic selector action MUST NOT create selector parameters for blob or clob child properties.
-The synthetic selector action MUST NOT create selector parameters for child properties whose ids are `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`.
-
-#### Scenario: Parent parameter is mandatory
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has a mandatory parameter typed as `Lease`
-
-#### Scenario: Parent parameter defaults to action target
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates defaults for the selector action on a `Lease` target
-- **THEN** the parent parameter default is that `Lease` target
-
-#### Scenario: Parent parameter is disabled
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework evaluates parameter usability for the selector action
-- **THEN** the parent parameter is disabled
-
-#### Scenario: Collection column scalar child properties become optional filters
-- **GIVEN** `Lease.items` renders eligible scalar child properties as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those column-backed scalar properties
-
-#### Scenario: Scalar child properties that are not collection columns are excluded from automatic filters
-- **GIVEN** `LeaseItem` has an eligible scalar property that is not rendered as a column of `Lease.items`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for that non-column scalar property
-
-#### Scenario: Child filter parameters follow collection column order
-- **GIVEN** `Lease.items` renders eligible scalar child properties as columns in a configured order
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action lists child filter parameters in the same relative order as the collection columns
-
-#### Scenario: Non-scalar child members are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection and a reference property that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the child collection or reference property
-
-#### Scenario: Blob and clob child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has blob and clob properties that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the blob or clob properties
-
-#### Scenario: Technical metadata child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has scalar properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`
diff --git a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/tasks.md b/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/tasks.md
deleted file mode 100644
index 84ed7d1d7ab..00000000000
--- a/openspec/changes/archive/2026-06-06-limit-selector-parameters-to-collection-columns/tasks.md
+++ /dev/null
@@ -1,18 +0,0 @@
-## 1. Selector Parameter Discovery
-
-- [x] 1.1 Update synthetic parented collection selector creation to derive child parameter candidates from the associated collection column model.
-- [x] 1.2 Preserve the mandatory disabled parent parameter as the first selector action parameter.
-- [x] 1.3 Apply the existing scalar, blob, clob, and technical metadata exclusions to the column-derived child parameter candidates.
-- [x] 1.4 Preserve child parameter ordering according to the collection column order.
-
-## 2. Tests
-
-- [x] 2.1 Add or update metamodel tests proving that scalar child properties rendered as collection columns become optional selector filters.
-- [x] 2.2 Add or update tests proving that eligible scalar child properties not rendered as collection columns are omitted.
-- [x] 2.3 Add or update tests proving that child selector filter parameters follow collection column order.
-- [x] 2.4 Keep coverage for parent parameter behavior and existing non-scalar, blob, clob, and technical metadata exclusions.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused metamodel selector action test suite.
-- [x] 3.2 Run `openspec validate limit-selector-parameters-to-collection-columns --strict`.
diff --git a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/.openspec.yaml b/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/.openspec.yaml
deleted file mode 100644
index b4c82a0a957..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-06
diff --git a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/design.md b/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/design.md
deleted file mode 100644
index 99b2354caa8..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/design.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Context
-
-Command export YAML wraps the replayable command DTO together with metadata derived from `CommandLogEntry#getResult()`.
-The current YAML field for that metadata is `returnedObject`, while the command log entry property is `result`.
-The requested change intentionally removes the old field name rather than preserving backward compatibility.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Rename the exported YAML field from `returnedObject` to `result`.
-- Rename the corresponding DTO property and accessor methods where appropriate.
-- Update replay import to read only the `result` field for command export DTOs.
-- Update tests, fixtures, and documentation/specs to use the new field name.
-
-**Non-Goals:**
-
-- Do not support deserializing the old `returnedObject` YAML field.
-- Align the nested result bookmark metadata shape with target and reference OID metadata by using `type` and `id`.
-- Do not change `CommandLogEntry#getResult()` semantics or replay result mapping behavior.
-- Do not change legacy multi-document `CommandDto` import support.
-
-## Decisions
-
-- Rename the DTO property to `result` instead of using a serialization alias on a `returnedObject` Java property.
- This aligns the Java model, YAML shape, and `CommandLogEntry` terminology.
- The alternative was adding a Jackson property annotation while leaving Java code unchanged, but that would preserve inconsistent internal naming.
-- Remove old-field compatibility.
- This satisfies the explicit requirement that backwards compatibility is unnecessary and avoids dual-property ambiguity during import.
- The alternative was to accept both names, but that would complicate validation and make exported examples less definitive.
-- Rename the nested result bookmark logical type field to `type`.
- This aligns result metadata with target OIDs and reference parameter OIDs, which already use `type` and `id`.
- The alternative was to keep `logicalTypeName`, but that would leave result metadata inconsistent with the other bookmark-like YAML structures.
-
-## Risks / Trade-offs
-
-- [Risk] Existing exported YAML files containing `returnedObject` will no longer import as result-bearing command export DTOs.
- Mitigation: document this as a breaking change and update tests/fixtures to use `result`.
-- [Risk] Some code or tests may still use old Java accessor names.
- Mitigation: search for `returnedObject` across source, tests, fixtures, docs, and OpenSpec artifacts during implementation.
-- [Risk] Replay import fallback to legacy `CommandDto` YAML could mask a malformed command export DTO.
- Mitigation: keep existing replay import behavior unchanged except for the renamed field, and validate with focused export/import tests.
diff --git a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/proposal.md b/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/proposal.md
deleted file mode 100644
index 586c8cee26e..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/proposal.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Why
-
-Command export and replay YAML currently names returned object metadata as `returnedObject`.
-The underlying `CommandLogEntry` property is named `result`, so renaming the YAML field to `result` makes exported and imported data align with the domain model.
-
-## What Changes
-
-- Rename the command export YAML returned object metadata field from `returnedObject` to `result`.
-- Update replay import to read `result` for `CommandExportDto` result bookmark metadata.
-- Remove support for the old `returnedObject` field; no backwards compatibility is required.
-- Update tests, fixtures, and documentation/specs to use `result` consistently.
-- **BREAKING**: Existing command export YAML using `returnedObject` must be regenerated or manually renamed to `result` before replay import.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `command-export-yaml-result`: exported and imported command result metadata uses the YAML field name `result` instead of `returnedObject`.
-
-## Impact
-
-- Affected code is expected around `CommandExportDto` serialization/deserialization and command replay import handling.
-- Affected tests are expected around command export YAML generation and replay import of result bookmark metadata.
-- Existing YAML fixtures or examples containing `returnedObject` need to be updated to `result`.
diff --git a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index b46fbdb1959..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,84 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Exported command YAML includes returned object metadata
-The system SHALL include result metadata for each exported command whose underlying `CommandLogEntry` has a non-null result bookmark.
-The result metadata SHALL be emitted under a YAML field named `result`.
-The result metadata SHALL contain `type` and `id` fields derived from the result bookmark.
-The system MUST NOT emit the old `returnedObject` field for result metadata.
-
-#### Scenario: Export command with result
-- **WHEN** a command selected for export has a non-null `CommandLogEntry#getResult()` bookmark
-- **THEN** the generated YAML contains result metadata for that command under field `result` with `type` set to the bookmark logical type name and `id` set to the bookmark identifier
-- **AND** the generated YAML does not contain field `returnedObject`
-
-#### Scenario: Export command without result
-- **WHEN** a command selected for export has a null `CommandLogEntry#getResult()` bookmark
-- **THEN** the generated YAML does not include result metadata for that command
-- **AND** the generated YAML does not contain field `returnedObject`
-
-### Requirement: Exported command YAML remains replay compatible
-The system SHALL preserve the command DTO data required by command replay import when adding result metadata to exported YAML.
-Command replay import SHALL first attempt to read the input as a multi-document stream of `CommandExportDto` values.
-If that fails, command replay import SHALL fall back to reading the input as a multi-document stream of `CommandDto` values.
-Command replay import MUST NOT support a single YAML list of `CommandDto` values.
-Command replay import MUST NOT support the old `returnedObject` field as a compatibility alias for `result`.
-
-#### Scenario: Import legacy multi-document command DTO YAML
-- **WHEN** command replay import receives a YAML file using the legacy multi-document `CommandDto` export shape
-- **THEN** the system imports the command DTOs as before
-
-#### Scenario: Import YAML with result metadata
-- **WHEN** command replay import receives a YAML file generated with result metadata
-- **THEN** the system imports the command DTOs needed for replay and stores the result metadata as the corresponding command log result when present
-
-#### Scenario: Reject command DTO list YAML
-- **WHEN** command replay import receives a YAML file containing a single list of `CommandDto` values
-- **THEN** the system rejects the import instead of importing the list entries
-
-### Requirement: Imported command export YAML stores returned object result
-The system SHALL store result metadata from each imported `CommandExportDto` as the result bookmark of the corresponding replay `CommandLogEntry`.
-The system SHALL read imported result metadata from a `CommandExportDto` field named `result`.
-The system MUST NOT read imported result metadata from the old `returnedObject` field.
-The system MUST NOT require the result bookmark to resolve to an existing domain object during import.
-
-#### Scenario: Import command export with result
-- **WHEN** command replay import receives a multi-document YAML file containing a `CommandExportDto` whose `result` has `type` and `id`
-- **THEN** the system persists the embedded command DTO for replay and sets the created `CommandLogEntry` result bookmark from that result metadata
-
-#### Scenario: Import command export without result
-- **WHEN** command replay import receives a multi-document YAML file containing a `CommandExportDto` without `result`
-- **THEN** the system persists the embedded command DTO for replay and leaves the created `CommandLogEntry` result bookmark unset
-
-#### Scenario: Import command export with old returnedObject field does not set result
-- **WHEN** command replay import receives a multi-document YAML file containing a `CommandExportDto` with old field `returnedObject` and without field `result`
-- **THEN** the system does not set the created `CommandLogEntry` result bookmark from `returnedObject`
-
-### Requirement: Exported command YAML includes logged safe action returned object metadata
-The system SHALL export safe action command log entries using the existing command export YAML shape when safe action command publishing created those entries.
-The system SHALL export synthetic parented collection selector action command log entries using the same command export YAML shape as other logged safe action entries.
-When a logged safe action entry has a non-null result bookmark, the exported YAML SHALL include result metadata under field `result` containing the bookmark logical type name and identifier.
-The system SHALL preserve compatibility with existing command replay import for exported safe action entries that use the `result` field.
-The system MUST NOT emit the old `returnedObject` field for logged safe action result metadata.
-
-#### Scenario: Export logged safe action command with result
-- **GIVEN** safe action command publishing is enabled
-- **AND** a safe action command log entry has result bookmark `demoCustomer:1`
-- **WHEN** the command is selected for export
-- **THEN** the generated YAML contains the embedded command DTO for the safe action invocation
-- **AND** the generated YAML contains result metadata under field `result` with type `demoCustomer` and id `1`
-- **AND** the generated YAML does not contain field `returnedObject`
-
-#### Scenario: Export logged selector action command with result
-- **GIVEN** synthetic parented collection selector action creation is enabled
-- **AND** safe action command publishing is enabled
-- **AND** a synthetic selector action command log entry has result bookmark `demoChild:1`
-- **WHEN** the selector action command is selected for export
-- **THEN** the generated YAML contains the embedded command DTO for the selector action invocation
-- **AND** the generated YAML contains result metadata under field `result` with type `demoChild` and id `1`
-- **AND** the generated YAML does not contain field `returnedObject`
-
-#### Scenario: Export command stream containing safe and state-changing commands
-- **GIVEN** a command export selection contains a logged safe action command followed by a state-changing command that uses the found object
-- **WHEN** the commands are exported
-- **THEN** the generated YAML preserves both command entries in replay order
-- **AND** the safe action entry includes its result metadata when available
diff --git a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/tasks.md b/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/tasks.md
deleted file mode 100644
index 563b3be1bfc..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-returned-object-to-result/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. DTO and Import/Export Implementation
-
-- [x] 1.1 Rename `CommandDtoUtils.CommandExportDto` result metadata property and accessors from `returnedObject` to `result`.
-- [x] 1.2 Update command replay import to read `ImportedCommandDto#getResult()` or equivalent renamed API and set `CommandLogEntry#setResult(...)` from that value.
-- [x] 1.3 Remove support for the old `returnedObject` YAML field; do not add Jackson aliases or compatibility setters for it.
-- [x] 1.4 Rename result bookmark metadata field from `logicalTypeName` to `type` for consistency with target and reference parameter OIDs.
-
-## 2. Tests and Fixtures
-
-- [x] 2.1 Update command export YAML tests and approval fixtures to emit `result:` and not `returnedObject:`.
-- [x] 2.2 Update command replay import tests to import result bookmark metadata from `result`.
-- [x] 2.3 Add or update coverage showing old `returnedObject` input is not treated as result metadata.
-- [x] 2.4 Search source, tests, fixtures, docs, and active OpenSpec artifacts for current-behavior `returnedObject` references and update them to `result` where appropriate.
-
-## 3. Validation
-
-- [x] 3.1 Run focused applib command DTO YAML tests.
-- [x] 3.2 Run focused command replay import tests.
-- [x] 3.3 Run `openspec validate rename-returned-object-to-result --strict`.
diff --git a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/.openspec.yaml b/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/.openspec.yaml
deleted file mode 100644
index b4c82a0a957..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-06
diff --git a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/design.md b/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/design.md
deleted file mode 100644
index b13baf41c58..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/design.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are framework-generated safe actions that support command recording for parent-to-child collection navigation.
-The current implementation uses a single reserved action id prefix constant in `ObjectSpecificationAbstract` and appends the parented collection id to produce deterministic action ids.
-The requested change is intentionally small, but it changes a framework-visible identifier that can appear in command export, replay, and tests.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Rename the reserved selector action id prefix to `__causeway_select_from_`.
-- Preserve deterministic action ids by keeping the collection id suffix unchanged.
-- Keep the user-facing action name `Select` unchanged.
-- Keep selector action synthesis, parameter behavior, invocation behavior, and command publishing behavior unchanged.
-- Update tests and OpenSpec requirements so the new reserved id is covered explicitly.
-
-**Non-Goals:**
-
-- Do not add compatibility aliases for the old `__causeway_select_` prefix.
-- Do not change command DTO shape beyond the synthetic action id value.
-- Do not rename the synthetic action display name.
-- Do not revisit selector eligibility, parameter filtering, or ordering rules.
-
-## Decisions
-
-- Replace the prefix constant in the selector synthesis utility rather than deriving the new id at call sites.
- This keeps all generated selector action ids consistent and avoids duplicated string construction.
- The alternative was to post-process ids in export or replay, but that would leave the metamodel with the less readable id and create split behavior.
-- Treat the prefix rename as a breaking identifier change.
- Existing stored command recordings that reference `__causeway_select_...` will not match the renamed synthetic action without data migration or regeneration.
- The alternative was to support both prefixes, but compatibility aliases would weaken the deterministic one-action-per-collection model and add unnecessary complexity for a readability improvement.
-- Keep the suffix as the associated collection id.
- This preserves the existing deterministic mapping from a parented collection to its selector action.
- The alternative was to include parent type or other metadata, but that is outside the requested rename and would broaden the compatibility impact.
-
-## Risks / Trade-offs
-
-- [Risk] Existing command recordings or tests may reference the old id prefix.
- Mitigation: document the rename as breaking in the proposal and update repository tests that assert the generated id.
-- [Risk] The new prefix may require updates in downstream replay fixtures or exported examples.
- Mitigation: search for the old prefix across source, tests, and OpenSpec artifacts during implementation.
-- [Risk] A partial update could leave code and specs describing different prefixes.
- Mitigation: validate the OpenSpec change and run selector action tests after implementation.
diff --git a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/proposal.md b/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/proposal.md
deleted file mode 100644
index 38d4d744f16..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/proposal.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## Why
-
-Synthetic parented collection selector action ids currently use the reserved prefix `__causeway_select_`.
-Renaming the prefix to `__causeway_select_from_` makes the generated ids read more clearly as actions that select from a specific collection while retaining deterministic framework-owned ids.
-
-## What Changes
-
-- Change the reserved synthetic parented collection selector action id prefix from `__causeway_select_` to `__causeway_select_from_`.
-- Preserve deterministic action id generation by continuing to append the associated collection id after the prefix.
-- Update tests and OpenSpec requirements that describe the reserved selector action id format.
-- **BREAKING**: Existing recordings, integrations, or assertions that reference the old synthetic action id prefix will need to use the new prefix.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `parented-collection-selector-actions`: the deterministic selector action identifier requirement changes to use the reserved `__causeway_select_from_` prefix.
-
-## Impact
-
-- Affected code is expected around synthetic selector action creation in `ObjectSpecificationAbstract`.
-- Affected tests are expected around parented collection selector action id generation and metadata assertions.
-- Exported command or replay data that stores synthetic selector action ids may need corresponding updates because the reserved id string changes.
diff --git a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 983f22eca78..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls command-log recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `ENABLED`, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize parented collection selector actions.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.parented-collection-selector-actions-enabled` boolean property to enable synthetic parented collection selector action creation.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action identifier SHALL use the reserved prefix `__causeway_select_from_` followed by the associated parented collection id.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Select` through name metadata equivalent to `@ActionLayout(named="Select")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when recording support is enabled for a parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier uses the reserved prefix `__causeway_select_from_`
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Select
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Select`
diff --git a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/tasks.md b/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/tasks.md
deleted file mode 100644
index 12c529e9a73..00000000000
--- a/openspec/changes/archive/2026-06-06-rename-selector-prefix-to-select-from/tasks.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## 1. Implementation
-
-- [x] 1.1 Update the synthetic parented collection selector action id prefix constant from `__causeway_select_` to `__causeway_select_from_`.
-- [x] 1.2 Verify selector action id construction still appends the associated parented collection id without changing display name, layout association, parameters, or invocation behavior.
-
-## 2. Tests and Documentation
-
-- [x] 2.1 Update selector action unit tests and any fixtures that assert the old `__causeway_select_` prefix.
-- [x] 2.2 Search source, tests, and OpenSpec artifacts for remaining references to the old prefix and update only the references that describe current behavior.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused selector action test suite for `ParentedCollectionSelectorActionUtilTest`.
-- [x] 3.2 Run `openspec validate rename-selector-prefix-to-select-from --strict`.
diff --git a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/design.md b/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/design.md
deleted file mode 100644
index e9b52be8995..00000000000
--- a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/design.md
+++ /dev/null
@@ -1,64 +0,0 @@
-## Context
-
-Synthetic parented collection navigate-to actions are currently created in `ObjectSpecificationAbstract.ParentedCollectionNavigationActionUtil` when command-log recording support is enabled.
-Those generated actions expose a stable reserved action id, static `Navigate To` naming, layout association metadata, secondary button styling, Font Awesome icon metadata, safe action semantics, command publishing metadata, validation, and invocation behavior.
-The requested reference navigation action should reuse the same viewer-facing and recording-facing contract, but the source association is a scalar reference property rather than a parented collection.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Generate one synthetic safe navigate-to action for each eligible scalar reference association when recording support is enabled.
-- Give reference navigation actions the same `__causeway_navigate_to_` prefix, `Navigate To` name, `btn-outline-secondary` CSS class, `hand-point-left` icon, and `associateWith` layout semantics as collection navigation actions.
-- Disable the generated action for a current object when the associated reference property evaluates to `null`.
-- Return the referenced object directly when the associated reference property is non-null.
-- Cover the behavior with metamodel-focused tests that do not depend on a specific viewer.
-
-**Non-Goals:**
-
-- Do not change existing parented collection navigation action behavior.
-- Do not add filter parameters or matching logic to scalar reference navigation actions.
-- Do not change ordinary reference property rendering or direct link traversal.
-- Do not make synthetic navigate-to action styling configurable.
-- Do not synthesize actions for value properties, collections, or references whose referenced type is not navigable as a domain object.
-
-## Decisions
-
-- Add a reference-specific synthetic action factory beside the parented collection factory rather than overloading collection matching code.
- Scalar reference navigation has no filter parameters and returns the property value directly, so sharing the collection matcher would add unnecessary branching and index semantics.
- Alternative considered: generalize the current collection factory into one large navigation factory.
- That would centralize constants, but it would also couple two different invocation models and make collection tests more fragile.
-
-- Share or mirror the static layout facet contract used by collection navigation actions.
- The generated reference action should expose ordinary metamodel facets equivalent to `@ActionLayout(named="Navigate To", associateWith="<propertyId>", cssClass="btn-outline-secondary", cssClassFa="hand-point-left")` so viewers and exporters can consume existing metadata paths.
- Alternative considered: rely on viewer conventions for synthetic action ids.
- That would not satisfy layout/export consistency and would leave command recording surfaces without reliable UI metadata.
-
-- Use the same reserved id prefix with the scalar reference property id as the suffix.
- The requested prefix is already the canonical synthetic navigate-to namespace, and using the association id keeps the action id deterministic and easy to associate with the source property.
- Alternative considered: add a reference-specific prefix such as `__causeway_navigate_to_reference_`.
- That would reduce theoretical collisions with collection ids but would diverge from the requested contract and from existing command recording naming.
-
-- Disable rather than hide generated reference navigation actions when the current reference value is `null`.
- This preserves a stable metamodel action list while preventing invocation that cannot produce a target object.
- Alternative considered: validate null during invocation only.
- That would give later and less useful feedback to viewers and recorders.
-
-- Install a marker facet for scalar reference navigation actions, separate from the parented collection marker facet.
- Tooling can then distinguish synthetic reference traversal from synthetic collection traversal even though both use the same action id prefix and layout presentation.
- Alternative considered: reuse the existing `ParentedCollectionNavigationFacet` for references.
- That would confuse consumers that expect the facet to carry a collection association.
-
-## Risks / Trade-offs
-
-- [Risk] A type could have a collection and scalar reference with the same association id, producing the same synthetic action id.
- → Mitigation: rely on existing member id clash reporting and add tests or guard logic to avoid creating duplicate synthetic actions when an action id already exists.
-
-- [Risk] Property access during usability or invocation could trigger lazy loading or domain exceptions.
- → Mitigation: follow existing association access APIs and surface a clear disabled or invocation failure reason consistent with other metamodel facets.
-
-- [Risk] Synthesizing additional actions could expose more commands to recording surfaces than expected.
- → Mitigation: keep the same recording-support and suppression gating used by collection navigation actions.
-
-- [Risk] The shared `__causeway_navigate_to_` prefix may make action ids ambiguous without association metadata.
- → Mitigation: always install marker and layout association facets so consumers can identify the action kind and source association.
diff --git a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/proposal.md b/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/proposal.md
deleted file mode 100644
index bb6c19cadef..00000000000
--- a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/proposal.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## Why
-
-Command recording can already model navigation from a parent object to a selected element of a parented collection, but it cannot model the simpler navigation step from an object to one of its scalar referenced objects through a generated action.
-Adding a synthetic reference navigation action gives recording and replay a stable action id and metamodel contract for traversing ordinary object references while preserving direct UI navigation behavior.
-
-## What Changes
-
-- Synthesize a safe `Navigate To` action for each eligible scalar reference association when command-log recording support is enabled.
-- Use the deterministic reserved action id prefix `__causeway_navigate_to_` followed by the reference association id.
-- Associate each synthetic action with its reference property through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-- Expose action layout metadata equivalent to `@ActionLayout(named="Navigate To", cssClass="btn-outline-secondary", cssClassFa="hand-point-left")`.
-- Disable the synthetic action for a current object when the associated reference value is `null`.
-- Return the referenced object when the associated reference value is non-null.
-- Preserve existing scalar reference rendering and direct link traversal behavior.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: Extend the synthetic navigate-to action contract from parented collections to scalar reference associations with equivalent naming, styling, association, enablement, and invocation semantics.
-
-## Impact
-
-- Affects synthetic action creation in `core/metamodel`, likely alongside `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil` and related navigation synthetic action facets.
-- Affects metamodel tests that cover generated navigate-to actions, marker metadata, layout association metadata, styling facets, usability, and invocation behavior.
-- Affects command recording and replay surfaces that enumerate actions for reference navigation when recording support is enabled.
-- Does not add dependencies and does not change ordinary reference rendering or direct link navigation when the synthetic action is unavailable.
diff --git a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index cfbeb458865..00000000000
--- a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,145 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Framework synthesizes navigate-to actions for scalar references
-The system SHALL synthesize a safe metamodel `ObjectAction` for each eligible scalar reference association whose owning type does not implement the command recording suppression marker interface when `causeway.extensions.command-log.recording-support` is `ENABLED`.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize scalar reference navigate-to actions.
-When a scalar reference association's owning type implements the command recording suppression marker interface, the system MUST NOT synthesize a scalar reference navigate-to action for that association.
-An eligible scalar reference association SHALL be allowed when its owning type is an entity or view model and its referenced type is an entity, view model, or abstract domain type.
-The synthetic action SHALL represent navigation from the current object to the object referenced by the associated scalar reference association.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action identifier SHALL use the reserved prefix `__causeway_navigate_to_` followed by the associated scalar reference association id.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the scalar reference association through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Navigate To` through name metadata equivalent to `@ActionLayout(named="Navigate To")`.
-The synthetic action SHALL have action layout CSS class metadata equivalent to `@ActionLayout(cssClass="btn-outline-secondary")`.
-The synthetic action SHALL have action layout Font Awesome metadata equivalent to `@ActionLayout(cssClassFa="hand-point-left")`.
-The synthetic action MUST NOT define action parameters.
-
-#### Scenario: Reference navigation action is not available by default
-- **GIVEN** a domain object type has a scalar reference to another domain object
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the domain object type
-- **THEN** the metamodel does not include a synthetic navigate-to action for that reference
-
-#### Scenario: Reference navigation action is available when recording support is enabled for an entity-owned reference
-- **GIVEN** an entity type has a scalar reference to another entity
-- **AND** command-log recording support is `ENABLED`
-- **AND** the entity type does not implement the command recording suppression marker interface
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for navigating to the referenced object
-- **AND** the synthetic action is associated with the reference owner type
-
-#### Scenario: Reference navigation action is available when recording support is enabled for a view-model-owned reference
-- **GIVEN** a view model type has a scalar reference to an entity
-- **AND** command-log recording support is `ENABLED`
-- **AND** the view model type does not implement the command recording suppression marker interface
-- **WHEN** the framework fully introspects the view model type
-- **THEN** the metamodel includes a synthetic safe action for navigating to the referenced object
-- **AND** the synthetic action is associated with the reference owner type
-
-#### Scenario: Reference navigation action is not added for marked owner type
-- **GIVEN** an entity or view model type has a scalar reference to another domain object
-- **AND** command-log recording support is `ENABLED`
-- **AND** the owner type implements the command recording suppression marker interface
-- **WHEN** the framework fully introspects the owner type
-- **THEN** the metamodel does not include a synthetic navigate-to action for that reference
-
-#### Scenario: Reference navigation action is not added for scalar value property
-- **GIVEN** an entity type has a scalar value property
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic navigate-to action for that value property
-
-#### Scenario: Reference navigation action id is deterministic
-- **GIVEN** the framework introspects the same scalar reference in two application runs
-- **WHEN** the synthetic navigate-to action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier uses the reserved prefix `__causeway_navigate_to_`
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic reference navigation actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic scalar reference navigate-to action
-
-#### Scenario: Reference navigation action is associated with its reference property
-- **GIVEN** an entity type `LeaseItem` has a scalar reference `lease`
-- **AND** command-log recording support is `ENABLED`
-- **AND** `LeaseItem` does not implement the command recording suppression marker interface
-- **WHEN** the framework synthesizes the navigate-to action for `lease`
-- **THEN** the action has layout association metadata for reference property id `lease`
-
-#### Scenario: Reference navigation action display name is Navigate To
-- **GIVEN** an entity type `LeaseItem` has a scalar reference `lease`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the navigate-to action for `lease`
-- **THEN** the action display name is `Navigate To`
-
-#### Scenario: Reference navigation action uses secondary button styling
-- **GIVEN** an entity type `LeaseItem` has a scalar reference `lease`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the navigate-to action for `lease`
-- **THEN** the action has CSS class metadata of `btn-outline-secondary`
-
-#### Scenario: Reference navigation action uses select navigation icon styling
-- **GIVEN** an entity type `LeaseItem` has a scalar reference `lease`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the navigate-to action for `lease`
-- **THEN** the action has Font Awesome metadata of `hand-point-left`
-
-#### Scenario: Reference navigation action has no parameters
-- **GIVEN** an entity type `LeaseItem` has a scalar reference `lease`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the navigate-to action for `lease`
-- **THEN** the action has no parameters
-
-### Requirement: Reference navigation action usability follows null reference state
-The synthetic scalar reference navigate-to action SHALL be disabled for a current object when the associated reference property value is `null`.
-The synthetic scalar reference navigate-to action SHALL remain visible in the metamodel when disabled because the associated reference property value is `null`.
-The synthetic scalar reference navigate-to action SHALL be enabled for a current object when the associated reference property value is non-null.
-The disabled reason SHALL clearly indicate that there is no referenced object to navigate to.
-
-#### Scenario: Null reference disables reference navigation action
-- **GIVEN** an object has an eligible scalar reference whose value is `null`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework evaluates usability for the synthetic navigate-to action on that object
-- **THEN** the navigate-to action is disabled with a clear reason
-
-#### Scenario: Non-null reference keeps reference navigation action enabled
-- **GIVEN** an object has an eligible scalar reference whose value is another domain object
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework evaluates usability for the synthetic navigate-to action on that object
-- **THEN** the navigate-to action is enabled
-
-### Requirement: Reference navigation action invocation returns referenced object
-The synthetic scalar reference navigate-to action SHALL access the associated reference property from the current action target.
-The synthetic scalar reference navigate-to action SHALL return the referenced object when the associated reference property value is non-null.
-The synthetic scalar reference navigate-to action MUST fail clearly if invocation is attempted without prior successful usability checking and the associated reference property value is `null`.
-
-#### Scenario: Non-null reference is returned
-- **GIVEN** an object has an eligible scalar reference whose value is another domain object
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the synthetic navigate-to action is invoked on that object
-- **THEN** the action returns the referenced object
-
-#### Scenario: Direct invocation fails for null reference
-- **GIVEN** a caller bypasses usability checking
-- **AND** an object has an eligible scalar reference whose value is `null`
-- **WHEN** the synthetic navigate-to action is invoked directly
-- **THEN** the invocation fails with a clear no-reference error
-
-### Requirement: Disabled reference navigation action creation preserves ordinary reference traversal
-The system SHALL preserve existing reference rendering and direct link traversal behavior when synthetic scalar reference navigate-to action creation is disabled.
-The system SHALL avoid adding synthetic scalar reference navigate-to actions to ordinary metamodel action lists unless the configuration property is enabled.
-
-#### Scenario: Ordinary reference browsing is unchanged by default
-- **GIVEN** a user views an object page containing a scalar reference to another object
-- **AND** synthetic reference navigate-to action creation is disabled
-- **WHEN** the viewer renders the reference
-- **THEN** the user can still navigate by selecting the rendered reference link
-- **AND** the metamodel does not include a synthetic navigate-to action for the reference
-
-#### Scenario: Command recording can include synthetic reference navigation actions after opt-in
-- **GIVEN** a command recording surface supports synthetic navigate-to actions
-- **AND** synthetic reference navigate-to action creation is enabled
-- **WHEN** the recorder enumerates actions for navigating a scalar reference
-- **THEN** the synthetic navigate-to action is available for recording the reference traversal step
diff --git a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/tasks.md b/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/tasks.md
deleted file mode 100644
index 6e369b22bfa..00000000000
--- a/openspec/changes/archive/2026-06-07-add-navigate-to-reference-synthetic-action/tasks.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## 1. Synthetic Reference Navigation Factory
-
-- [x] 1.1 Add a reference-navigation synthetic action factory alongside `ParentedCollectionNavigationActionUtil` and invoke it during action creation when recording support is enabled.
-- [x] 1.2 Apply the same eligibility gates as collection navigation for owner type, recording support, command recording suppression, and navigable referenced type.
-- [x] 1.3 Generate deterministic action ids using `__causeway_navigate_to_` plus the scalar reference association id while avoiding duplicate synthetic action ids.
-- [x] 1.4 Create parameterless safe synthetic actions that return the referenced type and install command publishing metadata.
-
-## 2. Facets and Runtime Behavior
-
-- [x] 2.1 Install marker metadata for scalar reference navigation actions so tooling can distinguish them from developer-authored actions and collection navigation actions.
-- [x] 2.2 Install static layout metadata equivalent to `named="Navigate To"`, `associateWith="<referenceId>"`, `cssClass="btn-outline-secondary"`, and `cssClassFa="hand-point-left"`.
-- [x] 2.3 Add a disabled facet that disables the action with a clear reason when the current reference value is `null`.
-- [x] 2.4 Add an invocation facet that reads the reference from the action target, returns the referenced object when non-null, and fails clearly for direct null-reference invocation.
-
-## 3. Tests
-
-- [x] 3.1 Add metamodel tests asserting scalar reference navigation actions are absent by default and present only when recording support is enabled.
-- [x] 3.2 Add metamodel tests for entity-owned and view-model-owned eligible references, suppression-marker exclusion, value-property exclusion, deterministic id, marker metadata, and zero parameters.
-- [x] 3.3 Add metamodel tests for layout association, display name, CSS class, and Font Awesome metadata.
-- [x] 3.4 Add usability and invocation tests for null and non-null reference values.
-- [x] 3.5 Add or update tests proving existing parented collection navigation behavior remains unchanged.
-
-## 4. Validation
-
-- [x] 4.1 Run the focused metamodel synthetic navigation test suite.
-- [x] 4.2 Run `openspec status --change "add-navigate-to-reference-synthetic-action"` and confirm the change is apply-ready.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/design.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/design.md
deleted file mode 100644
index 0879c8c96bb..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/design.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Context
-
-`CommandReplayResultMapping` is an abstract applib entity with concrete JDO and JPA persistence implementations.
-Existing replay mapping maintenance is list-and-find oriented; deletion is currently only possible indirectly through repository or database access.
-Causeway supports object-contributed actions as mixins, and the command log module already registers replay-related mixins through `CausewayModuleExtCommandLogApplib`.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Add a delete action contributed to `CommandReplayResultMapping` as a mixin.
-- Mark the action as `IDEMPOTENT_ARE_YOU_SURE` to require confirmation while preserving idempotent semantics.
-- Delete the current mapping through `RepositoryService` so the action works for both JDO and JPA concrete entity types.
-- Place the action in `CommandReplayResultMapping.layout.fallback.xml`.
-
-**Non-Goals:**
-- Do not add bulk delete actions to `CommandLogMenu`.
-- Do not add new repository finder methods.
-- Do not change replay conflict policy or automatic mapping creation behavior.
-
-## Decisions
-
-- Implement deletion as an applib mixin named `CommandReplayResultMapping_delete`.
- This keeps the abstract mapping entity focused on state and follows the existing command log pattern for replay object actions.
- The alternative was to add an action method directly to the abstract entity, but that would mix UI behavior into the entity contract.
-
-- Inject `RepositoryService` into the mixin and call `removeAndFlush` or the repository-service removal API used elsewhere in the codebase.
- This avoids persistence-module-specific dependencies and works against the concrete entity instance supplied to the mixin.
- The alternative was to extend `CommandReplayResultMappingRepository`, but deletion of a known object does not require a custom repository contract.
-
-- Use `SemanticsOf.IDEMPOTENT_ARE_YOU_SURE` with command and execution publishing disabled.
- The operation is destructive and should require user confirmation, but repeated user intent against the same object should not have additional semantic effect beyond the object being gone.
- The alternative was `NON_IDEMPOTENT_ARE_YOU_SURE`, but the user specifically requested an idempotent action.
-
-- Register the mixin in `CausewayModuleExtCommandLogApplib` and place `delete` in the fallback layout.
- Registration makes the action available consistently, while layout placement prevents it from relying on unreferenced action defaults.
- The alternative was to rely on `unreferencedActions`, but explicit placement is clearer for a destructive operation.
-
-## Risks / Trade-offs
-
-- Deleting a mapping can affect later replay input remapping → Require `ARE_YOU_SURE` confirmation and describe that the operation cannot be undone.
-- Layout action id must match the contributed action id → Use the conventional mixin suffix `_delete`, which contributes action id `delete`.
-- Repository service removal API naming may differ across framework versions → Follow existing project usage and validate with targeted applib tests.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/proposal.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/proposal.md
deleted file mode 100644
index f627f5fe696..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/proposal.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## Why
-
-Operators can inspect persisted replay result mappings but cannot remove an obsolete or incorrect mapping directly from the mapping page.
-Providing an explicit delete action makes replay mapping maintenance safer and more discoverable.
-
-## What Changes
-
-- Add a delete action for `CommandReplayResultMapping` as an applib mixin.
-- Make the delete action `IDEMPOTENT_ARE_YOU_SURE` so users must confirm the destructive operation.
-- Delete the selected persistent replay result mapping using the repository service.
-- Register the mixin with the command log applib module.
-- Update replay result mapping fallback layout XML to include the delete action.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `persistent-command-replay-mapping-listener`: Persisted replay result mappings can be deleted from the mapping entity UI using a confirmation-required action.
-
-## Impact
-
-- Affects the command log applib module by adding a `CommandReplayResultMapping` delete mixin.
-- Affects `CommandReplayResultMapping.layout.fallback.xml` to place the new action.
-- Requires tests for action semantics, repository-service deletion, module registration, and layout metadata.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/specs/persistent-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/specs/persistent-command-replay-mapping-listener/spec.md
deleted file mode 100644
index fd430b70560..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/specs/persistent-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Persistent replay mappings can be deleted from the entity UI
-The system SHALL provide a delete action on persisted replay result mapping entities.
-The delete action SHALL be implemented as a mixin contributed to `CommandReplayResultMapping`.
-The delete action SHALL use idempotent are-you-sure semantics.
-The delete action SHALL remove the selected replay result mapping from persistence.
-The delete action SHALL be included in the persisted replay result mapping fallback layout metadata.
-
-#### Scenario: User deletes a persisted replay mapping
-- **GIVEN** a persisted replay result mapping exists for recorded bookmark `demoInvoice:1`
-- **WHEN** a user confirms the replay mapping delete action
-- **THEN** the system removes that replay result mapping from persistence
-
-#### Scenario: Delete action requires confirmation
-- **WHEN** a user views a persisted replay result mapping
-- **THEN** the delete action is exposed with idempotent are-you-sure semantics
-
-#### Scenario: Delete action appears in layout
-- **WHEN** a user views a persisted replay result mapping using fallback layout metadata
-- **THEN** the layout includes the delete action for that replay result mapping
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/tasks.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/tasks.md
deleted file mode 100644
index 3ea56112e72..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-delete-action/tasks.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## 1. Delete Mixin Implementation
-
-- [x] 1.1 Create `CommandReplayResultMapping_delete` as a mixin contributed to `CommandReplayResultMapping`.
-- [x] 1.2 Configure the action with `SemanticsOf.IDEMPOTENT_ARE_YOU_SURE`, disabled command publishing, disabled execution publishing, and a clear cannot-be-undone description.
-- [x] 1.3 Inject `RepositoryService` and remove the mixed-in `CommandReplayResultMapping` instance from persistence.
-- [x] 1.4 Register the mixin in `CausewayModuleExtCommandLogApplib`.
-
-## 2. Layout Metadata
-
-- [x] 2.1 Update `CommandReplayResultMapping.layout.fallback.xml` to place the `delete` action explicitly.
-- [x] 2.2 Ensure the layout keeps existing bookmark and command interaction id fields unchanged.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add unit tests for the delete mixin action semantics and publishing configuration.
-- [x] 3.2 Add unit tests proving the delete mixin delegates removal of the mixed-in mapping to `RepositoryService`.
-- [x] 3.3 Add a module-registration test or equivalent assertion that the command log applib module imports the delete mixin.
-- [x] 3.4 Add or update layout metadata tests to verify the `delete` action is present.
-- [x] 3.5 Run `openspec validate add-replay-mapping-delete-action --strict`.
-- [x] 3.6 Run targeted Maven tests for the commandlog applib module.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/design.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/design.md
deleted file mode 100644
index e34c896580d..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/design.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Context
-
-The command log extension already has a persistent replay result mapping entity, an abstract repository contract, JDO/JPA concrete repositories, and a command log menu action that lists all persisted replay mappings.
-The repository currently supports `findAll()`, `findByRecordedBookmark(...)`, and `createAndPersist(...)`.
-The persistence entities currently define named queries for all mappings and recorded-bookmark lookup only.
-
-After identity replay results are recorded, replay mappings can support broader inspection workflows.
-Users need a changed-only view to focus on non-identity mappings, and they need lookup actions by both recorded and actual bookmarks.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Add repository methods for changed mappings and actual-bookmark lookup.
-- Expose command log menu actions for all mappings, changed mappings, recorded bookmark lookup, and actual bookmark lookup.
-- Update both JDO and JPA named queries so the abstract repository can implement the new finders consistently.
-- Keep menu actions hidden when no persistent replay mapping repository is available.
-
-**Non-Goals:**
-- Do not change how mappings are recorded during replay.
-- Do not add new persistent entities or tables.
-- Do not add the final ReplayableCommand UI that consumes these finders.
-- Do not add write or delete menu actions for replay mappings.
-
-## Decisions
-
-- Keep finder methods on `CommandReplayResultMappingRepository` rather than introducing a separate query service.
- The repository is already the abstraction used by the persistent listener and menu, and extending it keeps JDO and JPA support aligned.
-
-- Add `findChanged()` for non-identity mappings where recorded and actual bookmarks differ.
- This creates the explicit “changed mappings” view requested by users while preserving `findAll()` for the complete view.
-
-- Add `findByActualBookmark(Bookmark)` returning a list rather than an optional value.
- Recorded bookmark remains unique, but multiple recorded bookmarks can legitimately map to the same actual bookmark.
-
-- Add menu actions in `CommandLogMenu` next to the existing replay result mappings action.
- The all-mappings action can retain or rename the existing behavior, while new actions should use safe semantics and disabled command/execution publishing like the current listing action.
-
-- Add an index for `actualBookmark` in JDO and JPA persistence metadata.
- Actual-bookmark lookup is user-driven and should not require scanning all rows.
-
-## Risks / Trade-offs
-
-- [Risk] Query syntax for changed mappings differs between JDOQL and JPQL.
- → Mitigation: Add persistence-specific named queries and test through repository integration coverage.
-- [Risk] Existing UI action names may shift if the current all-mappings action is renamed.
- → Mitigation: Prefer adding clear actions while keeping existing behavior compatible where possible.
-- [Risk] `actualBookmark` is not unique.
- → Mitigation: Return a list for actual-bookmark lookup and document that multiple mappings can match.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/proposal.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/proposal.md
deleted file mode 100644
index c3eb6e22b86..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/proposal.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## Why
-
-Replay result mappings now represent every replayed result object, including identity results.
-Operators need menu actions and repository finders to inspect those mappings, distinguish changed mappings, and locate mappings by either recorded or actual bookmark while working toward a richer ReplayableCommand UI.
-
-## What Changes
-
-- Add repository finder support for all replay mappings, changed-only mappings, lookup by recorded bookmark, and lookup by actual bookmark.
-- Add command log menu actions for listing all replay mappings, listing changed replay mappings, finding by recorded bookmark, and finding by actual bookmark.
-- Keep the existing list action behavior available, but align naming and behavior with the new finder set.
-- Add persistence-specific named queries and indexes where needed for actual bookmark lookup and changed-only listing.
-- Add tests for repository finders and menu actions.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `persistent-command-replay-mapping-listener`: Add finder and menu requirements for querying persisted replay mappings by all, changed-only, recorded bookmark, and actual bookmark views.
-
-## Impact
-
-- Affects the command log applib repository contract and repository abstract implementation for replay result mappings.
-- Affects JDO and JPA replay result mapping entities through additional named queries and actual-bookmark indexing.
-- Affects `CommandLogMenu` by adding user-facing safe actions for the new replay mapping finders.
-- Affects command log applib tests and persistence integration tests.
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/specs/persistent-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/specs/persistent-command-replay-mapping-listener/spec.md
deleted file mode 100644
index e651a3e4f2a..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/specs/persistent-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,73 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Persistent replay mappings are represented by applib and persistence-specific types
-The system SHALL define an abstract applib replay result mapping entity that exposes recorded and actual bookmark properties.
-The system SHALL define an abstract applib repository for finding, listing, and creating replay result mappings.
-The abstract applib repository SHALL support listing all replay result mappings.
-The abstract applib repository SHALL support listing changed replay result mappings where the recorded bookmark and actual bookmark differ.
-The abstract applib repository SHALL support finding a replay result mapping by recorded bookmark.
-The abstract applib repository SHALL support finding replay result mappings by actual bookmark.
-The JDO command log persistence module SHALL provide a concrete replay result mapping entity and repository.
-The JPA command log persistence module SHALL provide a concrete replay result mapping entity and repository.
-
-#### Scenario: JDO module provides persistent mapping types
-- **WHEN** the command log JDO persistence module is active
-- **THEN** the system provides a concrete JDO replay result mapping entity and repository implementing the applib contracts
-
-#### Scenario: JPA module provides persistent mapping types
-- **WHEN** the command log JPA persistence module is active
-- **THEN** the system provides a concrete JPA replay result mapping entity and repository implementing the applib contracts
-
-#### Scenario: Repository lists changed replay mappings
-- **WHEN** persisted replay mappings include `demoInvoice:1` to `demoInvoice:1` and `demoInvoice:2` to `demoInvoice:3`
-- **THEN** the repository changed-mappings finder returns the mapping from `demoInvoice:2` to `demoInvoice:3`
-- **AND** the repository changed-mappings finder does not return the mapping from `demoInvoice:1` to `demoInvoice:1`
-
-#### Scenario: Repository finds replay mappings by actual bookmark
-- **WHEN** persisted replay mappings include recorded bookmark `demoInvoice:1` with actual bookmark `demoInvoice:9`
-- **AND** persisted replay mappings include recorded bookmark `demoInvoice:2` with actual bookmark `demoInvoice:9`
-- **THEN** the repository actual-bookmark finder for `demoInvoice:9` returns both persisted replay mappings
-
-### Requirement: Persistent replay mappings are listable from the command log menu
-The system SHALL provide a command log menu action that lists all persisted replay result mappings.
-The system SHALL provide a command log menu action that lists changed persisted replay result mappings where the recorded bookmark and actual bookmark differ.
-The system SHALL provide a command log menu action that finds a persisted replay result mapping by recorded bookmark.
-The system SHALL provide a command log menu action that finds persisted replay result mappings by actual bookmark.
-The system SHALL provide fallback layout metadata for the persisted replay result mapping entity.
-The list actions SHALL return persisted mappings using the abstract applib repository.
-The listed replay result mappings SHALL include identity replay results where the recorded and actual bookmarks are equal when the user asks for all mappings.
-The changed-mappings action MUST NOT return identity replay result mappings where the recorded and actual bookmarks are equal.
-The replay mapping menu actions MUST be hidden when no persistent replay result mapping repository is available.
-
-#### Scenario: User lists persisted replay mappings
-- **WHEN** a user invokes the command log menu action for all replay result mappings
-- **THEN** the system returns the persisted replay result mappings
-- **AND** each mapping displays its recorded and actual bookmarks
-
-#### Scenario: User lists persisted identity replay mappings
-- **WHEN** a persisted replay result mapping has recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-- **AND** a user invokes the command log menu action for all replay result mappings
-- **THEN** the system returns the persisted identity replay result mapping
-- **AND** the mapping displays recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-#### Scenario: User lists changed replay mappings
-- **WHEN** persisted replay mappings include `demoInvoice:1` to `demoInvoice:1` and `demoInvoice:2` to `demoInvoice:3`
-- **AND** a user invokes the command log menu action for changed replay result mappings
-- **THEN** the system returns the mapping from `demoInvoice:2` to `demoInvoice:3`
-- **AND** the system does not return the mapping from `demoInvoice:1` to `demoInvoice:1`
-
-#### Scenario: User finds replay mapping by recorded bookmark
-- **WHEN** a persisted replay result mapping has recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-- **AND** a user invokes the command log menu action to find by recorded bookmark `demoInvoice:1`
-- **THEN** the system returns the persisted replay result mapping with recorded bookmark `demoInvoice:1`
-
-#### Scenario: User finds no replay mapping by recorded bookmark
-- **WHEN** no persisted replay result mapping has recorded bookmark `demoInvoice:99`
-- **AND** a user invokes the command log menu action to find by recorded bookmark `demoInvoice:99`
-- **THEN** the system returns an empty result set
-
-#### Scenario: User finds replay mappings by actual bookmark
-- **WHEN** persisted replay result mappings include recorded bookmark `demoInvoice:1` with actual bookmark `demoInvoice:9`
-- **AND** persisted replay result mappings include recorded bookmark `demoInvoice:2` with actual bookmark `demoInvoice:9`
-- **AND** a user invokes the command log menu action to find by actual bookmark `demoInvoice:9`
-- **THEN** the system returns both persisted replay result mappings
diff --git a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/tasks.md b/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/tasks.md
deleted file mode 100644
index 5d2f4402eef..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replay-mapping-finders/tasks.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## 1. Repository finder contract
-
-- [x] 1.1 Add `findChanged()` and `findByActualBookmark(Bookmark)` to `CommandReplayResultMappingRepository`.
-- [x] 1.2 Implement the new finder methods in `CommandReplayResultMappingRepositoryAbstract` using named queries.
-- [x] 1.3 Add named query constants for changed mappings and actual-bookmark lookup to `CommandReplayResultMapping.Nq`.
-
-## 2. Persistence queries and indexes
-
-- [x] 2.1 Add JDO named queries for changed mappings and actual-bookmark lookup.
-- [x] 2.2 Add JDO index metadata for `actualBookmark`.
-- [x] 2.3 Add JPA named queries for changed mappings and actual-bookmark lookup.
-- [x] 2.4 Add JPA index metadata for `actualBookmark`.
-
-## 3. Command log menu actions
-
-- [x] 3.1 Keep or update the all replay mappings menu action to use the repository `findAll()` finder.
-- [x] 3.2 Add a safe command log menu action to list changed replay mappings.
-- [x] 3.3 Add a safe command log menu action to find a replay mapping by recorded bookmark.
-- [x] 3.4 Add a safe command log menu action to find replay mappings by actual bookmark.
-- [x] 3.5 Hide all replay mapping menu actions when no `CommandReplayResultMappingRepository` is available.
-
-## 4. Tests and validation
-
-- [x] 4.1 Update repository fake/test implementations for the new finder methods.
-- [x] 4.2 Add applib tests for changed-mapping and actual-bookmark finder behavior.
-- [x] 4.3 Add or update menu tests for all, changed, recorded-bookmark, and actual-bookmark actions.
-- [x] 4.4 Run focused command log applib and persistence tests covering replay mapping repository and menu behavior.
-- [x] 4.5 Run OpenSpec validation for `add-replay-mapping-finders` and fix any issues.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/design.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/design.md
deleted file mode 100644
index 5808f9f021e..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/design.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## Context
-
-`ReplayableCommand` already exposes a participants collection and an `openTarget` action associated with that collection.
-Parameter participants can now expose actual argument bookmarks and argument objects, but users do not have a corresponding command-level action to select and open an argument from the participants table.
-The action needs to distinguish between the recorded command parameter name and the resolved argument object.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add an `openArgument` command-level mixin associated with the `participants` collection.
-- Use action sequence `2` so it appears after the existing `openTarget` action.
-- Disable the action when there are no parameter participants.
-- Provide a `parameterName` action parameter with choices derived from parameter participants.
-- Default `parameterName` only when there is exactly one parameter participant.
-- Validate the selected parameter name when its participant has no actual bookmark for the argument.
-- Open the actual argument object for the selected parameter participant when it is available.
-
-**Non-Goals:**
-
-- Do not change participant derivation or replay mapping semantics.
-- Do not rename `parameterName` or the participant role `PARAMETER`.
-- Do not add persistence schema changes.
-- Do not change the existing `openTarget` action behaviour.
-
-## Decisions
-
-- Implement `openArgument` as a separate mixin rather than adding behaviour to participant rows so argument navigation remains command-level and associated with the same participants collection as `openTarget`.
-- Use `parameterName` as the action parameter because the user selects from recorded command parameter names, while the action opens the corresponding actual argument object.
-- Derive choices from current participants with role `PARAMETER` so the action reflects the same participant derivation and mapping rules as the table.
-- Return a default only when exactly one parameter participant exists to avoid silently choosing among multiple possible arguments.
-- Validate on `parameterName` when the selected participant has no actual bookmark because an actual bookmark is the minimum evidence that an argument can be opened or at least resolved.
-- Resolve and return the selected participant's argument object through the same bookmark lookup behaviour used by `ReplayableCommandParticipant#getArgument`.
-
-## Risks / Trade-offs
-
-- A participant may have an actual bookmark that cannot be resolved locally → The action can still fail to open an object unless validation also accounts for lookup failure during implementation.
-- Multiple parameter participants might share the same parameter name → Choices should preserve the names available from participants, but duplicated names could make selection ambiguous.
-- Calling `getParticipants()` from mixin support methods may repeat participant derivation → Keep the implementation simple unless profiling shows a performance issue.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/proposal.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/proposal.md
deleted file mode 100644
index dd10efda565..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/proposal.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## Why
-
-Replayable command participants can expose actual argument objects for reference parameters, but the command view currently has no direct action for opening one of those argument objects.
-Adding an `openArgument` action makes argument inspection consistent with the existing `openTarget` action while keeping navigation associated with the participants table.
-
-## What Changes
-
-- Add a command-level `openArgument` mixin associated with the `participants` collection.
-- Set the `openArgument` action layout sequence to `2`.
-- Disable `openArgument` when the replayable command has no parameter participants.
-- Add an `openArgument` action parameter named `parameterName`.
-- Populate `parameterName` choices from participant parameter names where role is `PARAMETER`.
-- Default `parameterName` to the only available parameter name when exactly one parameter participant exists, otherwise leave the default empty.
-- Validate `parameterName` so the action cannot proceed when the selected parameter participant has no actual bookmark for its argument.
-- Open the selected parameter participant's actual argument object when available.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Add an `openArgument` participants-associated action for navigating to actual argument objects from parameter participants.
-
-## Impact
-
-- Affects the command log applib replay UI and mixin registration.
-- Affects `ReplayableCommand` participant navigation tests.
-- Does not affect replay mapping SPI signatures or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 3c4b3277f71..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,71 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view SHALL expose an `openTarget` action associated with the participants collection.
-The `openTarget` action SHALL have layout sequence `1`.
-The `openTarget` action SHALL open the actual target object when a target participant has an actual target available.
-The `openTarget` action SHALL be disabled when no actual target object is available.
-The `ReplayableCommand` object view SHALL expose an `openArgument` action associated with the participants collection.
-The `openArgument` action SHALL have layout sequence `2`.
-The `openArgument` action SHALL be disabled when no parameter participants are available.
-The `openArgument` action SHALL define a `parameterName` parameter.
-The `parameterName` parameter choices SHALL be the parameter names of participants whose role is `PARAMETER`.
-The `parameterName` parameter SHALL default to the only parameter participant name when exactly one parameter participant is available.
-The `parameterName` parameter SHALL have no default when more than one parameter participant is available.
-The `openArgument` action SHALL validate the selected `parameterName` when the matching parameter participant has no actual bookmark for its argument.
-The `openArgument` action SHALL open the selected actual argument object when the matching parameter participant has an actual argument object available.
-Target and argument inspection and navigation SHALL be available through rows and actions associated with the participants collection.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User opens actual target from participants action
-- **WHEN** a replayable command target participant has an actual target object available
-- **THEN** the replayable command exposes an `openTarget` action associated with the participants collection
-- **AND** the `openTarget` action has layout sequence `1`
-- **AND** invoking the action opens the actual target object
-
-#### Scenario: User cannot open target without actual target
-- **WHEN** a replayable command has no target participant actual target object available
-- **THEN** the `openTarget` action is disabled
-
-#### Scenario: User opens actual argument from participants action
-- **WHEN** a replayable command parameter participant has parameter name `customer`
-- **AND** the parameter participant has an actual argument object available
-- **THEN** the replayable command exposes an `openArgument` action associated with the participants collection
-- **AND** the `openArgument` action has layout sequence `2`
-- **AND** the `parameterName` parameter choices include `customer`
-- **AND** invoking the action with `customer` opens the actual argument object
-
-#### Scenario: User cannot open argument without parameter participants
-- **WHEN** a replayable command has no participants with role `PARAMETER`
-- **THEN** the `openArgument` action is disabled
-
-#### Scenario: Single parameter participant defaults parameter name
-- **WHEN** a replayable command has exactly one parameter participant
-- **AND** the parameter participant has parameter name `customer`
-- **THEN** the `openArgument` action defaults `parameterName` to `customer`
-
-#### Scenario: Multiple parameter participants do not default parameter name
-- **WHEN** a replayable command has more than one parameter participant
-- **THEN** the `openArgument` action has no default `parameterName`
-
-#### Scenario: User cannot open argument without actual bookmark
-- **WHEN** a replayable command parameter participant has parameter name `customer`
-- **AND** the parameter participant has no actual bookmark
-- **THEN** validating the `openArgument` action `parameterName` parameter with `customer` rejects the selection
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/tasks.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/tasks.md
deleted file mode 100644
index d6117136899..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-argument/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. Open Argument Mixin
-
-- [x] 1.1 Add a `ReplayableCommand_openArgument` mixin associated with the `participants` collection.
-- [x] 1.2 Configure the `openArgument` action with layout sequence `2`.
-- [x] 1.3 Register the new mixin with the command log applib module.
-
-## 2. Action Behaviour
-
-- [x] 2.1 Disable `openArgument` when no participants have role `PARAMETER`.
-- [x] 2.2 Add a `parameterName` action parameter with choices from parameter participant names.
-- [x] 2.3 Default `parameterName` when exactly one parameter participant is available and leave it empty for multiple participants.
-- [x] 2.4 Validate the selected `parameterName` when the matching parameter participant has no actual bookmark.
-- [x] 2.5 Open the selected parameter participant's actual argument object when available.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add focused tests for action association, sequence, disabled state, choices, defaults, validation, and opening the selected argument.
-- [x] 3.2 Run the command log applib focused test suite for replayable command mapping.
-- [x] 3.3 Run OpenSpec validation for the change.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/design.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/design.md
deleted file mode 100644
index 17bac47d2f8..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/design.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## Context
-
-`ReplayableCommand` now exposes participants-associated `openTarget` and `openArgument` actions.
-Result participants can expose actual result bookmarks and result objects after replay succeeds.
-The participants collection should provide the same direct navigation affordance for actual results as it does for targets and arguments.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add an `openResult` command-level mixin associated with the `participants` collection.
-- Use action sequence `3` so it appears after `openTarget` and `openArgument`.
-- Disable the action when no actual result object is available.
-- Return the actual result object when a result participant resolves locally.
-
-**Non-Goals:**
-
-- Do not change result participant derivation or replay result mapping semantics.
-- Do not add action parameters for result selection.
-- Do not change the existing `openTarget` or `openArgument` action behaviour.
-- Do not add persistence schema changes.
-
-## Decisions
-
-- Implement `openResult` as a separate mixin to keep target, argument, and result navigation actions independent and consistently associated with `participants`.
-- Use sequence `3` because `openTarget` uses `1` and `openArgument` uses `2`.
-- Disable based on actual result object availability rather than only actual bookmark availability because the action opens an object.
-- Reuse `ReplayableCommandParticipant#getResult` for object lookup so the action follows the same best-effort resolution logic as the participant row.
-
-## Risks / Trade-offs
-
-- A result participant may have an actual bookmark that cannot resolve locally → The action remains disabled because there is no object to open.
-- Multiple result participants are not expected by current participant derivation → The action can open the first available actual result object if implementation ever sees more than one.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/proposal.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/proposal.md
deleted file mode 100644
index b36662d37f4..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Replayable command participants can show an actual result object after successful replay, but the command view has no direct participants-associated action to open it.
-Adding an `openResult` action completes the target, argument, and result navigation set on the participants table.
-
-## What Changes
-
-- Add a command-level `openResult` mixin associated with the `participants` collection.
-- Set the `openResult` action layout sequence to `3`.
-- Disable `openResult` when no actual result object is available.
-- Open the actual result object when a result participant has one available.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Add an `openResult` participants-associated action for navigating to an actual result object from result participants.
-
-## Impact
-
-- Affects the command log applib replay UI and mixin registration.
-- Affects `ReplayableCommand` participant navigation tests.
-- Does not affect replay mapping SPI signatures or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index e4c3a193abf..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,85 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view SHALL expose an `openTarget` action associated with the participants collection.
-The `openTarget` action SHALL have layout sequence `1`.
-The `openTarget` action SHALL open the actual target object when a target participant has an actual target available.
-The `openTarget` action SHALL be disabled when no actual target object is available.
-The `ReplayableCommand` object view SHALL expose an `openArgument` action associated with the participants collection.
-The `openArgument` action SHALL have layout sequence `2`.
-The `openArgument` action SHALL be disabled when no parameter participants are available.
-The `openArgument` action SHALL define a `parameterName` parameter.
-The `parameterName` parameter choices SHALL be the parameter names of participants whose role is `PARAMETER`.
-The `parameterName` parameter SHALL default to the only parameter participant name when exactly one parameter participant is available.
-The `parameterName` parameter SHALL have no default when more than one parameter participant is available.
-The `openArgument` action SHALL validate the selected `parameterName` when the matching parameter participant has no actual bookmark for its argument.
-The `openArgument` action SHALL open the selected actual argument object when the matching parameter participant has an actual argument object available.
-The `ReplayableCommand` object view SHALL expose an `openResult` action associated with the participants collection.
-The `openResult` action SHALL have layout sequence `3`.
-The `openResult` action SHALL open the actual result object when a result participant has an actual result object available.
-The `openResult` action SHALL be disabled when no actual result object is available.
-Target, argument, and result inspection and navigation SHALL be available through rows and actions associated with the participants collection.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User opens actual target from participants action
-- **WHEN** a replayable command target participant has an actual target object available
-- **THEN** the replayable command exposes an `openTarget` action associated with the participants collection
-- **AND** the `openTarget` action has layout sequence `1`
-- **AND** invoking the action opens the actual target object
-
-#### Scenario: User cannot open target without actual target
-- **WHEN** a replayable command has no target participant actual target object available
-- **THEN** the `openTarget` action is disabled
-
-#### Scenario: User opens actual argument from participants action
-- **WHEN** a replayable command parameter participant has parameter name `customer`
-- **AND** the parameter participant has an actual argument object available
-- **THEN** the replayable command exposes an `openArgument` action associated with the participants collection
-- **AND** the `openArgument` action has layout sequence `2`
-- **AND** the `parameterName` parameter choices include `customer`
-- **AND** invoking the action with `customer` opens the actual argument object
-
-#### Scenario: User cannot open argument without parameter participants
-- **WHEN** a replayable command has no participants with role `PARAMETER`
-- **THEN** the `openArgument` action is disabled
-
-#### Scenario: Single parameter participant defaults parameter name
-- **WHEN** a replayable command has exactly one parameter participant
-- **AND** the parameter participant has parameter name `customer`
-- **THEN** the `openArgument` action defaults `parameterName` to `customer`
-
-#### Scenario: Multiple parameter participants do not default parameter name
-- **WHEN** a replayable command has more than one parameter participant
-- **THEN** the `openArgument` action has no default `parameterName`
-
-#### Scenario: User cannot open argument without actual bookmark
-- **WHEN** a replayable command parameter participant has parameter name `customer`
-- **AND** the parameter participant has no actual bookmark
-- **THEN** validating the `openArgument` action `parameterName` parameter with `customer` rejects the selection
-
-#### Scenario: User opens actual result from participants action
-- **WHEN** a replayable command result participant has an actual result object available
-- **THEN** the replayable command exposes an `openResult` action associated with the participants collection
-- **AND** the `openResult` action has layout sequence `3`
-- **AND** invoking the action opens the actual result object
-
-#### Scenario: User cannot open result without actual result
-- **WHEN** a replayable command has no result participant actual result object available
-- **THEN** the `openResult` action is disabled
diff --git a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/tasks.md b/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/tasks.md
deleted file mode 100644
index c57e123fc16..00000000000
--- a/openspec/changes/archive/2026-06-07-add-replayable-command-open-result/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Open Result Mixin
-
-- [x] 1.1 Add a `ReplayableCommand_openResult` mixin associated with the `participants` collection.
-- [x] 1.2 Configure the `openResult` action with layout sequence `3`.
-- [x] 1.3 Register the new mixin with the command log applib module.
-
-## 2. Action Behaviour
-
-- [x] 2.1 Disable `openResult` when no result participant has an actual result object available.
-- [x] 2.2 Open the actual result object from the first result participant with an available actual result object.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add focused tests for action association, sequence, disabled state, and opening an actual result.
-- [x] 3.2 Run the command log applib focused test suite for replayable command mapping.
-- [x] 3.3 Run OpenSpec validation for the change.
diff --git a/openspec/changes/archive/2026-06-07-add-selector-action-styling/.openspec.yaml b/openspec/changes/archive/2026-06-07-add-selector-action-styling/.openspec.yaml
deleted file mode 100644
index b4c82a0a957..00000000000
--- a/openspec/changes/archive/2026-06-07-add-selector-action-styling/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-06
diff --git a/openspec/changes/archive/2026-06-07-add-selector-action-styling/design.md b/openspec/changes/archive/2026-06-07-add-selector-action-styling/design.md
deleted file mode 100644
index 99370ac60b1..00000000000
--- a/openspec/changes/archive/2026-06-07-add-selector-action-styling/design.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## Context
-
-Parented collection selector actions are synthesized in `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil` when command-log recording support is enabled.
-The current facet installation adds the static display name, collection layout association, selector marker, safe semantics, validation, invocation, and command publishing metadata.
-Viewer and layout export code already understand action `CssClassFacet` and static Font Awesome `FaFacet` metadata installed by ordinary `@ActionLayout` processing.
-This change only needs to make the synthetic selector action install the same style facets that a developer-authored action would expose.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Install a static action CSS class of `btn-outline-secondary` on every synthetic parented collection selector action.
-- Install a static Font Awesome icon of `hand-point-left` on every synthetic parented collection selector action.
-- Keep the existing selector action id, name, association, semantics, command publishing, parameters, validation, and invocation behavior unchanged.
-- Cover the new facets with metamodel tests so viewer-independent behavior is specified.
-
-**Non-Goals:**
-
-- Make selector action styling configurable in this change.
-- Change the generated action name or collection association metadata.
-- Change selector eligibility, parameter discovery, matching, validation, invocation, or command publishing behavior.
-- Add viewer-specific rendering logic.
-
-## Decisions
-
-- Add dedicated synthetic facet classes rather than trying to reuse annotation facet factories.
- Annotation facet classes such as `CssClassFacetForActionLayoutAnnotation` and `FaFacetForActionLayoutAnnotation` are designed around an `ActionLayout` annotation and are not directly reusable for synthetic actions.
- Dedicated classes can extend the same common facet bases, `CssClassFacetSimple` and `FaStaticFacetAbstract`, to expose equivalent metamodel semantics without fabricating an annotation.
-- Install the style facets in `installActionFacets(...)` alongside the existing name and layout group facets.
- This keeps all static synthetic action layout metadata in one place and ensures mixed-in collection selectors receive the same styling path as ordinary collection selectors.
-- Use literal constants for `btn-outline-secondary` and `hand-point-left` in the synthetic facet classes or action synthesis utility.
- The values are part of the default generated selector action contract, and there is no proposal requirement for runtime configuration.
-- Validate through `ParentedCollectionSelectorActionUtilTest` by asserting the selector action exposes `CssClassFacet` and static `FaFacet` values.
- This verifies metamodel behavior without coupling the change to a particular viewer implementation.
-
-## Risks / Trade-offs
-
-- [Risk] Viewers may interpret `btn-outline-secondary` differently or ignore it entirely.
- → Mitigation: expose standard layout facets only, matching existing `@ActionLayout` metadata, and leave rendering decisions to viewers.
-- [Risk] Font Awesome quick notation may require the same value shape as annotations.
- → Mitigation: use the annotation-equivalent quick notation `hand-point-left` and test the resulting static facet quick notation.
-- [Risk] Future requests may want the styling configurable per collection.
- → Mitigation: keep this change limited to a small default facet installation that can later be overridden or parameterized if a new requirement appears.
diff --git a/openspec/changes/archive/2026-06-07-add-selector-action-styling/proposal.md b/openspec/changes/archive/2026-06-07-add-selector-action-styling/proposal.md
deleted file mode 100644
index bdc1ee2667b..00000000000
--- a/openspec/changes/archive/2026-06-07-add-selector-action-styling/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions currently expose the correct name and collection association, but they do not provide the visual affordances expected for generated navigation actions.
-Adding default styling makes the generated `Select` action easier to recognize in viewers and aligns its metamodel facets with the equivalent developer-authored `@ActionLayout` declaration.
-
-## What Changes
-
-- Add layout facets to synthetic parented collection selector actions equivalent to `@ActionLayout(cssClass = "btn-outline-secondary", cssClassFa = "hand-point-left", ...)`.
-- Preserve the existing selector action name, collection association, invocation, validation, and parameter behavior.
-- Ensure the styling metadata is part of the synthesized action metamodel so viewers and layout exporters can consume it consistently.
-- No breaking changes.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: synthetic selector actions gain default action layout styling metadata.
-
-## Impact
-
-- Affects synthetic parented collection selector action facet installation in the metamodel.
-- Affects viewer rendering and layout export surfaces that already consume action `cssClass` and `cssClassFa` facets.
-- Adds or updates metamodel tests for selector action layout facets.
-- Does not change public application APIs, configuration properties, or selector matching semantics.
diff --git a/openspec/changes/archive/2026-06-07-add-selector-action-styling/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-add-selector-action-styling/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 0afd0f1e260..00000000000
--- a/openspec/changes/archive/2026-06-07-add-selector-action-styling/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,65 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls command-log recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `ENABLED`, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize parented collection selector actions.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.parented-collection-selector-actions-enabled` boolean property to enable synthetic parented collection selector action creation.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action identifier SHALL use the reserved prefix `__causeway_select_from_` followed by the associated parented collection id.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Select` through name metadata equivalent to `@ActionLayout(named="Select")`.
-The synthetic action SHALL have action layout CSS class metadata equivalent to `@ActionLayout(cssClass="btn-outline-secondary")`.
-The synthetic action SHALL have action layout Font Awesome metadata equivalent to `@ActionLayout(cssClassFa="hand-point-left")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when recording support is enabled for a parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier uses the reserved prefix `__causeway_select_from_`
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Select
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Select`
-
-#### Scenario: Synthetic action uses secondary button styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has CSS class metadata of `btn-outline-secondary`
-
-#### Scenario: Synthetic action uses select navigation icon styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has Font Awesome metadata of `hand-point-left`
diff --git a/openspec/changes/archive/2026-06-07-add-selector-action-styling/tasks.md b/openspec/changes/archive/2026-06-07-add-selector-action-styling/tasks.md
deleted file mode 100644
index 2ff1b3d7712..00000000000
--- a/openspec/changes/archive/2026-06-07-add-selector-action-styling/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Metamodel Facets
-
-- [x] 1.1 Add a synthetic action CSS class facet that exposes `btn-outline-secondary` using the existing `CssClassFacet` contract.
-- [x] 1.2 Add a synthetic action Font Awesome facet that exposes static quick notation `hand-point-left` using the existing `FaFacet` contract.
-- [x] 1.3 Install both styling facets when `ParentedCollectionSelectorActionUtil` creates a synthetic selector action.
-
-## 2. Tests
-
-- [x] 2.1 Add metamodel test coverage that a normal selector action exposes CSS class `btn-outline-secondary`.
-- [x] 2.2 Add metamodel test coverage that a normal selector action exposes Font Awesome quick notation `hand-point-left`.
-- [x] 2.3 Add or adjust coverage to ensure mixed-in collection selector actions receive the same styling facets if needed.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused `ParentedCollectionSelectorActionUtilTest` Maven test set.
-- [x] 3.2 Run `openspec validate add-selector-action-styling --strict`.
diff --git a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/.openspec.yaml b/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/design.md b/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/design.md
deleted file mode 100644
index 848d01fbf1b..00000000000
--- a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/design.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## Context
-
-Parented collection selector actions are synthesized by `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil` when command-log recording support is enabled.
-The current runtime eligibility rule permits entity-owned collections with entity, view model, or abstract element types.
-It only permits view-model-owned collections in unit tests, and then only when the element type is also a view model.
-This prevents selectors on useful runtime view models such as the PetClinic home page, whose collections return `PetOwner` and `Visit` entities.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Allow selector action synthesis for view-model-owned collections at runtime.
-- Use the same element-type eligibility for entity and view-model owners.
-- Preserve the existing command-log recording support gate.
-- Preserve existing selector styling, naming, parameters, validation, invocation, and command publishing behavior.
-- Add regression coverage for view-model owners with entity elements.
-
-**Non-Goals:**
-
-- Change selector matching semantics.
-- Change which child properties become filter parameters.
-- Create selectors when command-log recording support is disabled.
-- Add application-specific logic for PetClinic or home page view models.
-- Add viewer rendering changes.
-
-## Decisions
-
-- Replace the owner-specific eligibility rule with a rule based on supported owner and element domain types.
- Entity and view-model owners should both be eligible because the selector invocation already reads the collection from the supplied parent object and does not depend on persistence identity of the parent.
-- Keep element eligibility constrained to entity, view model, or abstract domain types.
- This preserves the existing intent that selector actions navigate to a selected domain object rather than arbitrary scalar collection elements.
-- Remove the unit-test-only view-model exception instead of adding another special case.
- The runtime behavior should be explicit and testable, and unit tests should follow the same eligibility rule as production.
-- Validate with metamodel tests that a view-model owner with entity collection elements receives a selector action.
- Existing tests already cover entity owners and view-model element behavior.
-
-## Risks / Trade-offs
-
-- [Risk] More synthetic actions may appear in applications that have command-log recording support enabled and expose view-model collections.
- → Mitigation: this only applies after the existing opt-in property is enabled, and generated actions use the reserved synthetic marker and deterministic id.
-- [Risk] Some view-model collections may be expensive to evaluate during selector invocation.
- → Mitigation: selector invocation already evaluates the collection only when validating or invoking the action, matching existing entity-owned behavior.
-- [Risk] View-model-owned collections may not be semantically parented in every application.
- → Mitigation: the existing feature already synthesizes only from metamodel collection associations and remains gated by the command-log recording support opt-in.
diff --git a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/proposal.md b/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/proposal.md
deleted file mode 100644
index a2c156e5037..00000000000
--- a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions currently work for entity-owned collections but are unnecessarily restricted away from ordinary runtime view models.
-View models such as the PetClinic home page can expose entity collections that should be recordable and navigable using the same selector mechanism.
-
-## What Changes
-
-- Remove the runtime restriction that only entity-owned parented collections can receive synthetic selector actions.
-- Allow view-model-owned collections to receive selector actions when their element type is an entity, view model, or abstract domain type.
-- Preserve the existing command-log recording support opt-in, selector action styling, parameters, validation, invocation, and disabled-by-default behavior.
-- No breaking changes.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: selector action synthesis applies to eligible view-model-owned collections as well as entity-owned collections.
-
-## Impact
-
-- Affects selector action eligibility in the metamodel synthesis path.
-- Affects applications with command-log recording support enabled that expose eligible collections from view models.
-- Adds or updates metamodel tests for view-model-owned collections with entity or view-model elements.
-- Does not change public APIs, configuration properties, selector matching semantics, or viewer rendering logic.
diff --git a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index ab8899f1cd8..00000000000
--- a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,73 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls command-log recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `ENABLED`, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize parented collection selector actions.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.parented-collection-selector-actions-enabled` boolean property to enable synthetic parented collection selector action creation.
-An eligible parented collection association SHALL be allowed when its owning type is an entity or view model and its element type is an entity, view model, or abstract domain type.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action identifier SHALL use the reserved prefix `__causeway_select_from_` followed by the associated parented collection id.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Select` through name metadata equivalent to `@ActionLayout(named="Select")`.
-The synthetic action SHALL have action layout CSS class metadata equivalent to `@ActionLayout(cssClass="btn-outline-secondary")`.
-The synthetic action SHALL have action layout Font Awesome metadata equivalent to `@ActionLayout(cssClassFa="hand-point-left")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** a domain object type has a parented collection of child entities
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the domain object type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when recording support is enabled for an entity-owned parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action is available when recording support is enabled for a view-model-owned parented collection
-- **GIVEN** a view model type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework fully introspects the view model type
-- **THEN** the metamodel includes a synthetic safe action for selecting one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier uses the reserved prefix `__causeway_select_from_`
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Select
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Select`
-
-#### Scenario: Synthetic action uses secondary button styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has CSS class metadata of `btn-outline-secondary`
-
-#### Scenario: Synthetic action uses select navigation icon styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has Font Awesome metadata of `hand-point-left`
diff --git a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/tasks.md b/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/tasks.md
deleted file mode 100644
index 3819d56e69a..00000000000
--- a/openspec/changes/archive/2026-06-07-allow-view-model-selector-actions/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Eligibility Rule
-
-- [x] 1.1 Update selector action eligibility so entity and view-model owners are both supported at runtime.
-- [x] 1.2 Keep selector action element eligibility constrained to entity, view model, or abstract domain types.
-- [x] 1.3 Remove the unit-test-only view-model eligibility special case.
-
-## 2. Tests
-
-- [x] 2.1 Add metamodel test coverage for a view-model owner with entity collection elements.
-- [x] 2.2 Verify view-model-owned selector actions keep existing name, association, styling, parameter, validation, and invocation behavior through focused assertions where practical.
-- [x] 2.3 Preserve existing entity-owner selector action coverage.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused `ParentedCollectionSelectorActionUtilTest` Maven test set.
-- [x] 3.2 Run `openspec validate allow-view-model-selector-actions --strict`.
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/.openspec.yaml b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/design.md b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/design.md
deleted file mode 100644
index ada248d60a1..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/design.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## Context
-
-Replay result mappings are created when `CommandReplayMappingListener#onReplayResult(...)` receives the recorded result bookmark, actual result bookmark, and replayed `CommandLogEntry`.
-The existing `CommandReplayResultMapping` abstraction and concrete JDO/JPA entities store only recorded and actual bookmarks.
-The in-memory listener stores only the actual bookmark in a `Map<Bookmark, Bookmark>`.
-The replayed `CommandLogEntry` already exposes the interaction id, so the change can capture the originating interaction without changing the replay notification SPI signature.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Store the replayed command interaction id that first created each replay result mapping.
-- Preserve that first interaction id when replay reports an existing mapping again.
-- Keep persistent and in-memory replay mapping behavior aligned.
-- Show the command interaction id in replay result mapping layout metadata.
-
-**Non-Goals:**
-- Do not add a new finder by command interaction id unless a later change requests it.
-- Do not change conflict policy semantics for repeated mappings.
-- Do not change the `CommandReplayMappingListener` method signatures.
-
-## Decisions
-
-- Reuse `CommandLogEntry#getInteractionId()` as the source of the mapping origin.
- The replay notification already receives the command log entry, so this avoids an SPI change and keeps custom listener compatibility.
- The alternative was to add an explicit interaction id parameter to `onReplayResult(...)`, but that would create broader API churn without adding information.
-
-- Add `commandInteractionId` to the abstract applib mapping contract and to concrete JDO/JPA entities as a nullable `UUID` property.
- Nullable storage protects upgrades and existing rows that predate the field.
- The alternative was a non-null field, but that would require a data migration for existing mappings and complicate rollout.
-
-- Extend repository creation to accept the command interaction id, while preserving a compatibility overload if useful during implementation.
- The persistent listener should create new rows with the interaction id and should not mutate existing rows during idempotent or conflict handling.
- The alternative was to set the field after creation, but one creation path keeps the persistence contract simpler and easier to test.
-
-- Replace the in-memory listener value type with a small mapping value that stores both actual bookmark and command interaction id.
- This keeps the in-memory storage strategy semantically equivalent to persistent storage.
- The alternative was to leave in-memory storage unchanged, but that would make the data structure diverge from the new mapping contract.
-
-## Risks / Trade-offs
-
-- Existing persisted rows will have no command interaction id after upgrade → Treat the property as optional and display it only when available.
-- JDO query classes may need regeneration after adding the field → Include generated-source refresh or targeted compile in implementation tasks.
-- Layout metadata can become stale if the property id differs from the Java getter name → Use `commandInteractionId` consistently in the property, column order, and fallback layout.
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/proposal.md b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/proposal.md
deleted file mode 100644
index e7c31831af2..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Replay result mappings currently show the recorded and actual bookmarks but not the command interaction that first created the mapping.
-Capturing the originating command interaction id improves auditability and makes it possible to trace a remapping back to the replayed command that produced it.
-
-## What Changes
-
-- Add the command interaction id that created a replay result mapping to the replay mapping data model.
-- Persist the command interaction id on new `CommandReplayResultMapping` entities for both JDO and JPA persistence modules.
-- Keep the originally stored command interaction id unchanged when replay reports a mapping that already exists.
-- Extend the in-memory replay mapping data structure so it tracks the originating command interaction id alongside the actual bookmark.
-- Update the replay result mapping layout metadata so the command interaction id is visible in the UI.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `command-replay-result-mapping`: Replay result mapping observations expose and retain the command interaction id that produced the mapping.
-- `persistent-command-replay-mapping-listener`: Persistent replay result mappings store and display the command interaction id that first created the mapping.
-
-## Impact
-
-- Affects the command log applib replay mapping SPI implementations and replay result mapping repository contract.
-- Affects the JDO and JPA command log persistence entity mappings and generated query classes if applicable.
-- Affects replay result mapping fallback layout XML and column order metadata.
-- Requires tests for new mapping creation, idempotent existing mappings, and UI/layout metadata.
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 046e224121c..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay result mapping observes command interaction id
-The system SHALL make the replayed command interaction id available when a replay result mapping observation is handled.
-The built-in replay mapping listener implementations SHALL capture the interaction id from the `CommandLogEntry` supplied to `onReplayResult(...)` when they create a new mapping.
-When the supplied command log entry has no interaction id, the system SHALL still record or retain the replay result mapping without an interaction id.
-The system MUST NOT require a `CommandReplayMappingListener` SPI signature change to expose this interaction id.
-
-#### Scenario: Replay result observation includes command interaction id
-- **WHEN** command replay succeeds for an imported command whose interaction id is `11111111-1111-1111-1111-111111111111`
-- **AND** the command has recorded result bookmark `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **THEN** the built-in replay mapping listener records a replay result mapping associated with command interaction id `11111111-1111-1111-1111-111111111111`
-
-#### Scenario: Replay result observation has no command interaction id
-- **WHEN** command replay notifies a built-in replay mapping listener with recorded result bookmark `demoInvoice:1` and actual result bookmark `demoInvoice:2`
-- **AND** the supplied command log entry has no interaction id
-- **THEN** the built-in replay mapping listener records or retains the replay result mapping without a command interaction id
-
-#### Scenario: Existing SPI signature is preserved
-- **WHEN** an application implements `CommandReplayMappingListener#onReplayResult(Bookmark, Bookmark, CommandLogEntry)`
-- **THEN** the implementation remains source-compatible with the replay result mapping SPI
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/persistent-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/persistent-command-replay-mapping-listener/spec.md
deleted file mode 100644
index e4120621b8f..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/specs/persistent-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Persistent replay mappings retain originating command interaction id
-The persistent replay mapping listener SHALL store the replayed command interaction id when it creates a new replay result mapping and the command interaction id is available.
-The persistent replay mapping listener MUST NOT update the stored command interaction id when a replay result notification matches an existing mapping.
-The persistent replay mapping listener MUST NOT update the stored command interaction id when a replay result notification conflicts with an existing mapping and the configured conflict policy logs and continues.
-The persisted replay result mapping entity SHALL expose the command interaction id as an optional property.
-The JDO and JPA command log persistence modules SHALL provide storage for the command interaction id property.
-
-#### Scenario: New persistent mapping records command interaction id
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** the replayed command interaction id is `11111111-1111-1111-1111-111111111111`
-- **THEN** the system persists a mapping with command interaction id `11111111-1111-1111-1111-111111111111`
-
-#### Scenario: Existing idempotent mapping keeps original command interaction id
-- **GIVEN** a persisted replay result mapping for recorded bookmark `demoInvoice:1` has actual bookmark `demoInvoice:2`
-- **AND** the mapping has command interaction id `11111111-1111-1111-1111-111111111111`
-- **WHEN** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** the later replayed command interaction id is `22222222-2222-2222-2222-222222222222`
-- **THEN** the persisted mapping keeps command interaction id `11111111-1111-1111-1111-111111111111`
-
-#### Scenario: Existing conflicting mapping keeps original command interaction id when conflict is logged
-- **GIVEN** the replay mapping conflict policy is configured to log and continue
-- **AND** a persisted replay result mapping for recorded bookmark `demoInvoice:1` has actual bookmark `demoInvoice:2`
-- **AND** the mapping has command interaction id `11111111-1111-1111-1111-111111111111`
-- **WHEN** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **AND** the later replayed command interaction id is `22222222-2222-2222-2222-222222222222`
-- **THEN** the persisted mapping keeps command interaction id `11111111-1111-1111-1111-111111111111`
-
-### Requirement: Persistent replay mapping layout displays command interaction id
-The system SHALL include the command interaction id property in the fallback layout metadata for persisted replay result mappings.
-The system SHALL include the command interaction id in replay result mapping column order metadata when such metadata is provided.
-
-#### Scenario: User views replay mapping command interaction id
-- **WHEN** a persisted replay result mapping has command interaction id `11111111-1111-1111-1111-111111111111`
-- **AND** a user views the replay result mapping
-- **THEN** the mapping layout displays the command interaction id
diff --git a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/tasks.md b/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/tasks.md
deleted file mode 100644
index 676442b833d..00000000000
--- a/openspec/changes/archive/2026-06-07-capture-replay-mapping-command-interaction-id/tasks.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## 1. Applib Mapping Contract
-
-- [x] 1.1 Add an optional `commandInteractionId` property to `CommandReplayResultMapping` with domain event metadata and accessors.
-- [x] 1.2 Update `CommandReplayResultMapping#init(...)` to accept and set the command interaction id while preserving bookmark initialization.
-- [x] 1.3 Update `CommandReplayResultMappingRepository#createAndPersist(...)` and `CommandReplayResultMappingRepositoryAbstract` to create mappings with the command interaction id.
-- [x] 1.4 Preserve compatibility where useful by delegating any existing two-bookmark creation path to the new creation path with a null command interaction id.
-
-## 2. Replay Mapping Listener Implementations
-
-- [x] 2.1 Update `CommandReplayMappingListenerPersistent` to pass `CommandLogEntry#getInteractionId()` when creating a new persistent mapping.
-- [x] 2.2 Ensure `CommandReplayMappingListenerPersistent` does not update `commandInteractionId` for idempotent existing mappings or logged conflicts.
-- [x] 2.3 Replace the in-memory listener value type with a mapping data structure that stores actual bookmark and command interaction id.
-- [x] 2.4 Ensure in-memory listener lookup and conflict handling preserve existing behavior while retaining the first command interaction id.
-
-## 3. Persistence and Layout Metadata
-
-- [x] 3.1 Add nullable command interaction id storage to the JDO `CommandReplayResultMapping` entity.
-- [x] 3.2 Add nullable command interaction id storage to the JPA `CommandReplayResultMapping` entity.
-- [x] 3.3 Regenerate or update JDO query classes if required by the added persistent field.
-- [x] 3.4 Update `CommandReplayResultMapping.layout.fallback.xml` to display `commandInteractionId`.
-- [x] 3.5 Update `CommandReplayResultMapping.columnOrder.fallback.txt` to include `commandInteractionId`.
-
-## 4. Tests and Validation
-
-- [x] 4.1 Add applib tests proving new persistent mappings capture the replayed command interaction id.
-- [x] 4.2 Add tests proving existing idempotent mappings keep their original command interaction id.
-- [x] 4.3 Add tests proving logged conflict handling keeps the original command interaction id.
-- [x] 4.4 Add in-memory listener tests for capturing and retaining the first command interaction id in the internal data structure.
-- [x] 4.5 Add or update persistence integration tests for JDO and JPA mapping entities.
-- [x] 4.6 Validate layout and column order metadata includes `commandInteractionId`.
-- [x] 4.7 Run `openspec validate capture-replay-mapping-command-interaction-id --strict`.
-- [x] 4.8 Run targeted Maven tests for commandlog applib, persistence-jdo, and persistence-jpa modules.
diff --git a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/.openspec.yaml b/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/design.md b/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/design.md
deleted file mode 100644
index 3b58be71fea..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/design.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Context
-
-Synthetic parented collection selector actions are currently created when command-log recording support is enabled and the collection association is eligible.
-The action validation facet already prevents invocation when no child object matches the supplied parameters.
-However, for an empty collection there can never be a matching child, so the action should be disabled before the user opens or submits it.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Disable each synthetic selector action dynamically when its associated collection is empty for the current action target.
-- Keep selector actions enabled for non-empty collections so existing selection, filtering, validation, and invocation behavior is unchanged.
-- Use the standard action disabled facet mechanism so viewers and command recording surfaces consume the behavior normally.
-- Cover empty and non-empty collection usability with metamodel tests.
-
-**Non-Goals:**
-
-- Hide selector actions for empty collections.
-- Remove selector actions from the metamodel when collections are empty.
-- Change no-match or ambiguous-match validation messages.
-- Change selector parameter discovery, matching, return values, styling, or command publishing.
-- Add viewer-specific rendering logic.
-
-## Decisions
-
-- Add a dedicated disabled facet for synthetic parented collection selector actions.
- The parent parameter already has its own disabled facet, but action-level empty-collection usability is a separate concern and should be represented on the action itself.
-- Evaluate emptiness from the current action target and the selector facet's associated collection.
- This keeps the behavior dynamic and avoids making collection size part of metamodel synthesis.
-- Disable only when the collection has no elements.
- For non-empty collections, validation remains responsible for checking whether the supplied filter values identify exactly one child.
-- Return a clear disabled reason such as `No items to select.`.
- The exact text can be concise because detailed no-match feedback remains in action validation after parameters are supplied.
-
-## Risks / Trade-offs
-
-- [Risk] Checking emptiness may evaluate the collection when rendering action usability.
- → Mitigation: selector validation and invocation already evaluate the collection, and the check only needs to determine whether any item exists.
-- [Risk] Some collections may be lazily loaded or computed.
- → Mitigation: the disabled facet should use the same metamodel collection access path as selector invocation rather than introducing a separate mechanism.
-- [Risk] Empty collection disabled state may change as data changes.
- → Mitigation: evaluate dynamically for the current target each time action usability is requested.
diff --git a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/proposal.md b/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/proposal.md
deleted file mode 100644
index 9ab75a513da..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-Synthetic parented collection selector actions are useful only when the associated collection has at least one row to select from.
-When the collection is empty, offering an enabled `Select` action creates a poor user experience because invocation can only fail with a no-match validation result.
-
-## What Changes
-
-- Disable synthetic parented collection selector actions when their associated collection is empty for the current parent object.
-- Preserve selector action synthesis, visibility, styling, parameters, validation, invocation, and command publishing behavior for non-empty collections.
-- Keep the disabled behavior dynamic so an action becomes enabled again when the associated collection has rows.
-- No breaking changes.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: selector action usability now reflects whether the associated collection has any selectable rows for the current parent object.
-
-## Impact
-
-- Affects synthetic selector action usability evaluation in the metamodel.
-- Affects viewers and command recording surfaces that already respect action disabled facets.
-- Adds or updates metamodel tests for empty and non-empty selector collection usability.
-- Does not change selector creation, matching, validation messages, invocation behavior, public APIs, or configuration properties.
diff --git a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index f163ffa6137..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Selector actions are disabled for empty collections
-The synthetic selector action SHALL be disabled for a current parent object when the associated parented collection has no elements.
-The synthetic selector action SHALL remain visible in the metamodel when disabled because the associated collection is empty.
-The synthetic selector action SHALL be enabled for a current parent object when the associated parented collection has at least one element.
-The synthetic selector action SHALL keep existing validation behavior for non-empty collections, including no-match and ambiguous-match validation after filter parameters are supplied.
-
-#### Scenario: Empty collection disables selector action
-- **GIVEN** an object has an eligible parented collection with no elements
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework evaluates usability for the synthetic selector action on that object
-- **THEN** the selector action is disabled with a clear reason
-
-#### Scenario: Non-empty collection keeps selector action enabled
-- **GIVEN** an object has an eligible parented collection with at least one element
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework evaluates usability for the synthetic selector action on that object
-- **THEN** the selector action is enabled
-
-#### Scenario: Non-empty collection still validates filter matches
-- **GIVEN** an object has an eligible parented collection with at least one element
-- **AND** command-log recording support is `ENABLED`
-- **WHEN** the framework validates synthetic selector action parameters that match no collection element
-- **THEN** validation rejects the action with a clear no-match reason
diff --git a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/tasks.md b/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/tasks.md
deleted file mode 100644
index e0c581aeafb..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-empty-selector-actions/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Action Disabled Facet
-
-- [x] 1.1 Add an action-level disabled facet for synthetic parented collection selector actions.
-- [x] 1.2 Implement the disabled facet so it reads the associated collection from the current action target and vetoes usability when the collection is empty.
-- [x] 1.3 Install the disabled facet when `ParentedCollectionSelectorActionUtil` creates a synthetic selector action.
-
-## 2. Tests
-
-- [x] 2.1 Add metamodel test coverage that an empty associated collection disables the selector action with a clear reason.
-- [x] 2.2 Add metamodel test coverage that a non-empty associated collection leaves the selector action enabled.
-- [x] 2.3 Verify existing no-match validation behavior remains unchanged for non-empty collections.
-
-## 3. Validation
-
-- [x] 3.1 Run the focused `ParentedCollectionSelectorActionUtilTest` Maven test set.
-- [x] 3.2 Run `openspec validate disable-empty-selector-actions --strict`.
diff --git a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/.openspec.yaml b/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/design.md b/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/design.md
deleted file mode 100644
index 93d28cc7a64..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/design.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Context
-
-`ReplayableCommand_replayOrRetry` is the action users invoke from the replayable command UI to replay or retry an imported command.
-The action currently delegates to `ReplayableCommand#tryReplayOrRetry`, which already has a guard path through `disableReplayOrRetry()`, but the mixin action currently returns `null` from `disableAct()` and is therefore always enabled.
-A command that has just been recorded on the primary system has replay state `UNDEFINED` and is not yet in the imported replay queue.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Disable `ReplayableCommand#replayOrRetry` for `UNDEFINED` replay state.
-- Keep `ReplayableCommand#replayOrRetry` enabled for `PENDING`, `OK`, and `FAILED` replay states.
-- Keep the action disabled for states that are not replayable from the command view, including `EXPORTED` and `EXCLUDED`.
-- Keep direct invocation guarded even if UI disablement is bypassed.
-
-**Non-Goals:**
-
-- Do not change how commands transition into `UNDEFINED`, `EXPORTED`, `PENDING`, `OK`, `FAILED`, or `EXCLUDED`.
-- Do not change export/import workflows.
-- Do not remove the ability to retry an `OK` command when a user intentionally invokes replay/retry.
-
-## Decisions
-
-- Restore `ReplayableCommand_replayOrRetry#disableAct()` to delegate to `ReplayableCommand#disableReplayOrRetry()`.
- This makes the UI action use the same guard as direct invocation.
- Alternative considered: duplicate replay-state checks in the mixin action.
- That would be simpler locally but risks drift from the invocation guard.
-
-- Define replay/retry action availability as `PENDING`, `OK`, or `FAILED` only.
- `PENDING` is the normal imported state, `FAILED` supports retry, and `OK` remains allowed because existing comments indicate legitimate retry use cases after success.
- `UNDEFINED` is excluded because it represents a newly recorded command, not an imported replay candidate.
-
-- Keep the guard as a replay-state predicate close to `ReplayState` or `ReplayableCommand.CommandRecord`.
- A named predicate makes tests explicit and avoids relying on older `isPendingOrFailed` terminology that excludes `OK`.
-
-## Risks / Trade-offs
-
-- [Risk] Existing users may have relied on clicking replay/retry for newly recorded `UNDEFINED` commands.
- → Mitigation: this state is not a replay queue state; users should export/import commands before replaying them.
-
-- [Risk] The disable reason may mention only some non-replayable states.
- → Mitigation: update the message to describe the allowed states rather than a partial list of disallowed states.
diff --git a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/proposal.md b/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/proposal.md
deleted file mode 100644
index 57a3a9c36ee..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-A newly recorded command has replay state `UNDEFINED`, meaning it has not been exported/imported into the replay workflow yet.
-Enabling `ReplayableCommand#replayOrRetry` for that state suggests the command can be replayed immediately, but replay/retry should only be available for commands that are pending replay, have replayed successfully, or have failed and can be retried.
-
-## What Changes
-
-- Disable `ReplayableCommand#replayOrRetry` when the replay state is `UNDEFINED`.
-- Keep `ReplayableCommand#replayOrRetry` enabled when replay state is `PENDING`, `OK`, or `FAILED`.
-- Keep the existing behavior that the replay action is unavailable for non-replayable states such as `EXPORTED` or `EXCLUDED`.
-- Update action disablement tests to cover the newly recorded `UNDEFINED` state.
-
-## Capabilities
-
-### New Capabilities
-
-- `replayable-command-actions`: Defines replayable command action availability and state-driven enablement.
-
-### Modified Capabilities
-
-- None.
-
-## Impact
-
-- Affects `ReplayableCommand_replayOrRetry` and the underlying `ReplayableCommand` replay/retry guard logic in `extensions/core/commandlog/applib`.
-- Affects tests for replayable command action enablement.
-- Does not change command recording, export, import, or replay execution semantics.
diff --git a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/specs/replayable-command-actions/spec.md b/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/specs/replayable-command-actions/spec.md
deleted file mode 100644
index 3b4243774ea..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/specs/replayable-command-actions/spec.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replay or retry action is enabled only for replay states
-The system SHALL expose a replay-or-retry action for replayable commands.
-The replay-or-retry action SHALL be enabled when the replay state is `PENDING`.
-The replay-or-retry action SHALL be enabled when the replay state is `OK`.
-The replay-or-retry action SHALL be enabled when the replay state is `FAILED`.
-The replay-or-retry action MUST be disabled when the replay state is `UNDEFINED`.
-The replay-or-retry action MUST be disabled when the replay state is `EXPORTED`.
-The replay-or-retry action MUST be disabled when the replay state is `EXCLUDED`.
-If invocation is attempted while the replay-or-retry action is disabled, the system MUST NOT replay the command.
-
-#### Scenario: Pending command can be replayed
-- **GIVEN** a replayable command has replay state `PENDING`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is enabled
-
-#### Scenario: Successful command can be replayed again
-- **GIVEN** a replayable command has replay state `OK`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is enabled
-
-#### Scenario: Failed command can be retried
-- **GIVEN** a replayable command has replay state `FAILED`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is enabled
-
-#### Scenario: Newly recorded command cannot be replayed
-- **GIVEN** a replayable command has replay state `UNDEFINED`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is disabled
-
-#### Scenario: Exported command cannot be replayed from the command view
-- **GIVEN** a replayable command has replay state `EXPORTED`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is disabled
-
-#### Scenario: Excluded command cannot be replayed
-- **GIVEN** a replayable command has replay state `EXCLUDED`
-- **WHEN** the framework evaluates the replay-or-retry action
-- **THEN** the replay-or-retry action is disabled
-
-#### Scenario: Direct invocation is guarded for non-replay state
-- **GIVEN** a caller bypasses UI disablement
-- **AND** a replayable command has replay state `UNDEFINED`
-- **WHEN** the caller invokes replay-or-retry directly
-- **THEN** the system does not replay the command
diff --git a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/tasks.md b/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/tasks.md
deleted file mode 100644
index f84a44eda11..00000000000
--- a/openspec/changes/archive/2026-06-07-disable-undefined-replay-or-retry/tasks.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## 1. Replay State Predicate
-
-- [x] 1.1 Add or update a replay-state predicate that returns true only for `PENDING`, `OK`, and `FAILED`.
-- [x] 1.2 Update `ReplayableCommand#disableReplayOrRetry()` to use the new allowed-state predicate and report a clear allowed-states message.
-- [x] 1.3 Ensure `ReplayableCommand#tryReplayOrRetry()` continues to guard direct invocation through `disableReplayOrRetry()`.
-
-## 2. Action Disablement
-
-- [x] 2.1 Update `ReplayableCommand_replayOrRetry#disableAct()` to delegate to `ReplayableCommand#disableReplayOrRetry()`.
-- [x] 2.2 Confirm the action remains enabled for `PENDING`, `OK`, and `FAILED` replay states.
-- [x] 2.3 Confirm the action is disabled for `UNDEFINED`, `EXPORTED`, and `EXCLUDED` replay states.
-
-## 3. Tests
-
-- [x] 3.1 Add focused tests for `ReplayableCommand#disableReplayOrRetry()` across all replay states.
-- [x] 3.2 Add or update tests proving `ReplayableCommand_replayOrRetry#disableAct()` delegates to the replayable command guard.
-- [x] 3.3 Add or update tests proving direct replay/retry invocation is still guarded when replay state is `UNDEFINED`.
-
-## 4. Validation
-
-- [x] 4.1 Run the focused command log applib replayable command tests.
-- [x] 4.2 Run `openspec status --change "disable-undefined-replay-or-retry"` and confirm the change is apply-ready.
diff --git a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/.openspec.yaml b/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/design.md b/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/design.md
deleted file mode 100644
index c8ecd9447a5..00000000000
--- a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/design.md
+++ /dev/null
@@ -1,69 +0,0 @@
-## Context
-
-The previous change introduced command-log-local `PauseLoggingEvent` and `ResumeLoggingEvent` classes in the command-log extension.
-Because testing fixtures applib must not depend on the command-log extension, initial fixture script installation could not publish those events directly.
-The workaround added fixture-specific initial-installing and initial-installed events that the command-log extension listened to alongside the pause and resume events.
-
-That bridge works but adds unnecessary concepts.
-The pause and resume intent is not command-log-extension-specific from the publisher's perspective: publishers only need to ask any installed command logging implementation to ignore commands in a scope.
-Core applib is the common API surface available to fixture scripts and command-log implementations.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Move command logging pause and resume event types to core applib so they are available to all modules.
-- Rename the events to `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent` to make their purpose explicit.
-- Have initial fixture script installation publish those core applib events directly.
-- Simplify the command-log listener to consume only the two core applib event types.
-- Remove the fixture-specific initial fixture installing and installed bridge events.
-
-**Non-Goals:**
-
-- Do not change the pause-depth semantics or command subscriber behavior while paused.
-- Do not add a hard dependency from testing fixtures applib to command-log applib.
-- Do not introduce a new command logging service API beyond event classes.
-- Do not change fixture script execution or transaction behavior.
-
-## Decisions
-
-### Place the events in core applib command service package
-
-Add `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent` under the core applib command service API area, for example `org.apache.causeway.applib.services.command`.
-This package already hosts command-related application APIs such as `Command`, `CommandExecutorService`, and the command recording suppression marker.
-
-Alternative considered: place the events under a generic applib events package.
-That would make the package less discoverable for command logging users and separate the events from related command service APIs.
-
-### Rename the events rather than preserve aliases
-
-Replace `PauseLoggingEvent` and `ResumeLoggingEvent` with `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent`.
-The explicit names avoid confusion with audit, execution, application, or framework logging.
-
-Alternative considered: keep deprecated aliases in command-log applib.
-The current events are newly introduced in this branch of work, so aliases would preserve unnecessary API surface and keep the old coupling around.
-
-### Publish core events directly from the initial fixture installer
-
-Update `InitialFixtureScriptsInstaller` to post `PauseCommandLoggingEvent` before invoking `FixtureScripts#run(...)` and `ResumeCommandLoggingEvent` in a `finally` block.
-This removes the need for fixture-specific bridge events while preserving the existing fixture script execution path.
-
-Alternative considered: continue publishing fixture-specific events and translate them in command-log applib.
-That keeps extra event classes and listener methods that exist only to work around event location.
-
-### Keep the listener focused on pause state only
-
-Update `CommandLogPauseStateListener` so it only listens to the core applib pause and resume events and updates `CommandLogPauseState`.
-The listener no longer needs imports from testing fixtures applib for initial fixture event types.
-
-Alternative considered: merge pause state and listener into `CommandSubscriberForCommandLog`.
-Keeping listener state separate remains cleaner and easier to test.
-
-## Risks / Trade-offs
-
-- [Risk] Moving events to core applib exposes them as a broader API than the command-log extension-local classes.
- → Mitigation: name and JavaDoc them explicitly as command logging events and keep behavior implemented only by modules that choose to listen.
-- [Risk] Existing tests or imports still reference old command-log event classes or fixture bridge events.
- → Mitigation: update all references and remove the old classes so stale imports fail at compile time.
-- [Risk] Publishing pause events when no command-log extension is installed has no visible effect.
- → Mitigation: this is acceptable for application events; publishers do not need to know whether a listener is installed.
diff --git a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/proposal.md b/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/proposal.md
deleted file mode 100644
index f253f46ec83..00000000000
--- a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The command logging pause and resume events currently live in the command-log extension, so fixture code cannot use them directly without introducing an undesirable dependency from testing fixtures to command-log.
-Moving the events to core applib gives any module a stable, shared application-event API for scoped command-log suppression and lets fixture scripts use the same events that the command-log listener consumes.
-
-## What Changes
-
-- Move the pause and resume command logging events from command-log applib to core applib.
-- Rename `PauseLoggingEvent` to `PauseCommandLoggingEvent` and `ResumeLoggingEvent` to `ResumeCommandLoggingEvent`.
-- Update initial fixture script installation to publish the core applib pause and resume events directly, rather than fixture-specific installing and installed events.
-- Simplify the command-log pause/resume listener so it only listens for the core applib pause and resume command logging events.
-- Remove the fixture-specific initial script installing and installed events introduced only to bridge command-log module dependencies.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `command-recording-suppression`: Clarifies that scoped command-log pause and resume use the core applib `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent` API.
-
-## Impact
-
-- Affects core applib by adding command logging pause and resume event classes under the command service API area.
-- Affects command-log applib by changing imports, removing extension-local event classes, and simplifying the pause state listener.
-- Affects testing fixtures applib by publishing core applib command logging pause and resume events around initial fixture script installation.
-- Affects tests that refer to the old command-log-local event names or fixture-specific bridge events.
diff --git a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/specs/command-recording-suppression/spec.md b/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/specs/command-recording-suppression/spec.md
deleted file mode 100644
index 27f88dffadd..00000000000
--- a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/specs/command-recording-suppression/spec.md
+++ /dev/null
@@ -1,62 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Command log persistence can be paused and resumed
-The system SHALL provide `PauseCommandLoggingEvent` in core applib as an application-event based mechanism to pause command log persistence.
-The system SHALL provide `ResumeCommandLoggingEvent` in core applib as an application-event based mechanism to resume command log persistence after a previous pause.
-Command logging implementations SHALL listen for the core applib pause and resume events without requiring event publishers to depend on a command logging implementation module.
-While command log persistence is paused, the command-log subscriber MUST NOT create new command log entries for published commands.
-While command log persistence is paused, the command-log subscriber MUST NOT sync existing command log entries for published command lifecycle updates.
-After command log persistence is resumed, subsequent eligible commands MUST remain persistable by the normal command-log subscriber flow.
-Nested pause scopes MUST NOT resume command log persistence until each active pause scope has been resumed.
-
-#### Scenario: Paused logging skips command entry creation
-- **GIVEN** command-log persistence is enabled
-- **AND** command log persistence has been paused by publishing `PauseCommandLoggingEvent`
-- **WHEN** a command reaches the ready notification
-- **THEN** the system does not create a command log entry for that command
-
-#### Scenario: Paused logging skips command entry synchronization
-- **GIVEN** command-log persistence is enabled
-- **AND** command log persistence has been paused by publishing `PauseCommandLoggingEvent`
-- **WHEN** a command reaches the started or completed notification
-- **THEN** the system does not sync a command log entry for that command notification
-
-#### Scenario: Resumed logging restores normal persistence
-- **GIVEN** command-log persistence is enabled
-- **AND** command log persistence was paused by publishing `PauseCommandLoggingEvent` and has then been resumed by publishing `ResumeCommandLoggingEvent`
-- **WHEN** a subsequent eligible command reaches the ready notification
-- **THEN** the system can create a command log entry for that command through the normal command-log subscriber flow
-
-#### Scenario: Nested pause requires matching resumes
-- **GIVEN** command-log persistence is enabled
-- **AND** command log persistence has been paused twice by publishing `PauseCommandLoggingEvent` twice
-- **WHEN** command log persistence is resumed once by publishing `ResumeCommandLoggingEvent` once
-- **THEN** command log persistence remains paused
-- **WHEN** command log persistence is resumed a second time by publishing `ResumeCommandLoggingEvent` a second time
-- **THEN** subsequent eligible commands can be persisted through the normal command-log subscriber flow
-
-### Requirement: Initial fixture script commands are not logged
-The system SHALL publish the core applib `PauseCommandLoggingEvent` while a configured initial fixture script is being installed during application startup.
-The system MUST publish the core applib `ResumeCommandLoggingEvent` after the initial fixture script installation completes.
-The system MUST publish the core applib `ResumeCommandLoggingEvent` if the initial fixture script installation fails.
-The pause MUST apply only to command-log persistence and MUST NOT prevent the fixture script from executing its domain logic normally.
-The initial fixture script installation path MUST NOT require a dependency from testing fixtures applib to command-log applib.
-
-#### Scenario: Initial fixture script commands are suppressed
-- **GIVEN** command-log persistence is enabled
-- **AND** an application has a configured initial fixture script
-- **WHEN** the system installs the initial fixture script during startup
-- **THEN** commands produced by that initial fixture script are not persisted as command log entries
-- **AND** the fixture script domain logic still executes normally
-
-#### Scenario: Logging resumes after successful initial fixture installation
-- **GIVEN** command-log persistence is enabled
-- **AND** an application has installed its configured initial fixture script during startup
-- **WHEN** a subsequent eligible command is published after initial fixture installation completes
-- **THEN** the system can persist that command as a command log entry through the normal command-log subscriber flow
-
-#### Scenario: Logging resumes after failed initial fixture installation
-- **GIVEN** command-log persistence is enabled
-- **AND** an application has a configured initial fixture script that fails during startup installation
-- **WHEN** command processing continues after the failed initial fixture installation scope exits
-- **THEN** command log persistence is no longer paused because of the initial fixture installation scope
diff --git a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/tasks.md b/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/tasks.md
deleted file mode 100644
index 1795be97682..00000000000
--- a/openspec/changes/archive/2026-06-07-move-command-logging-events-to-applib/tasks.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## 1. Core Applib Events
-
-- [x] 1.1 Add `PauseCommandLoggingEvent` to core applib under the command service API package with JavaDoc describing scoped command-log persistence suppression.
-- [x] 1.2 Add `ResumeCommandLoggingEvent` to core applib under the command service API package with JavaDoc describing matching resume behavior and nested pause semantics.
-- [x] 1.3 Remove the command-log applib `PauseLoggingEvent` and `ResumeLoggingEvent` classes.
-
-## 2. Command Log Listener Simplification
-
-- [x] 2.1 Update `CommandLogPauseStateListener` to import and listen for the core applib `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent` classes.
-- [x] 2.2 Remove listener methods and imports for fixture-specific initial fixture installing and installed events.
-- [x] 2.3 Verify `CommandLogPauseState` and `CommandSubscriberForCommandLog` continue to use the existing depth-counted pause state behavior.
-
-## 3. Fixture Script Integration
-
-- [x] 3.1 Update `InitialFixtureScriptsInstaller` to publish `PauseCommandLoggingEvent` before invoking the configured initial fixture script.
-- [x] 3.2 Update `InitialFixtureScriptsInstaller` to publish `ResumeCommandLoggingEvent` in the existing `finally` path.
-- [x] 3.3 Remove fixture-specific `InitialFixtureScriptsInstallingEvent` and `InitialFixtureScriptsInstalledEvent` classes.
-- [x] 3.4 Ensure testing fixtures applib depends only on core applib for command logging pause and resume events, not on command-log applib.
-
-## 4. Tests and Verification
-
-- [x] 4.1 Update command-log integration tests to use `PauseCommandLoggingEvent` and `ResumeCommandLoggingEvent`.
-- [x] 4.2 Update initial fixture installer tests to verify direct publication of the core applib pause and resume command logging events.
-- [x] 4.3 Run focused tests for testing fixtures applib and command-log persistence that cover pause/resume and initial fixture installation.
-- [x] 4.4 Run `openspec validate move-command-logging-events-to-applib --strict` and fix any proposal/spec/task issues.
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/.openspec.yaml b/openspec/changes/archive/2026-06-07-record-all-replay-results/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/design.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/design.md
deleted file mode 100644
index 395324c4896..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/design.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Context
-
-`CommandReplayMappingListener` currently combines two related replay responsibilities.
-Before replay execution, `remap(CommandLogEntry, Bookmark)` lets a listener return a replacement bookmark for a recorded command target or reference-valued parameter.
-After successful replay, `onReplayResultMapped(Bookmark, Bookmark, CommandLogEntry)` tells the listener about the recorded and actual result bookmarks.
-
-The replay execution path already notifies the SPI when both recorded and actual result bookmarks are available, including identity results.
-The in-memory and persistent built-in listeners currently discard identity result notifications before storing anything.
-That made sense when the store represented only non-identity remappings, but the next UI goal needs the stored data to represent every object encountered as a replay result.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Rename the SPI methods to `lookup(...)` and `onReplayResult(...)` so their names match their broadened responsibilities.
-- Store or persist identity result notifications as first-class replay result records.
-- Keep existing lookup behavior so later replay inputs can still be replaced by the actual bookmark associated with a recorded bookmark.
-- Keep existing conflict policy behavior for repeated notifications with different actual bookmarks.
-- Update tests and call sites to use the renamed SPI methods.
-
-**Non-Goals:**
-- Do not add the ReplayableCommand UI changes in this proposal.
-- Do not change command export format or imported command DTO semantics.
-- Do not add new tables, entities, or repository contracts beyond changing what the existing replay result mapping repository stores.
-- Do not introduce compatibility bridge methods for the old SPI method names unless implementation constraints require a short transitional step.
-
-## Decisions
-
-- Treat replay result records as observations rather than only remappings.
- This means `onReplayResult(...)` stores the first observed actual bookmark for a recorded result bookmark even when both bookmarks are equal.
- The alternative was to add a separate observation listener or repository, but that would duplicate the existing recorded-to-actual shape and delay the UI work.
-
-- Rename `remap(...)` to `lookup(...)` rather than introducing a second method.
- The method returns the actual bookmark already associated with a recorded bookmark, so `lookup` describes both identity and non-identity records without implying that a value must differ.
- The alternative was `resolve(...)`, but that can imply object resolution and this SPI deliberately works with bookmarks without resolving objects.
-
-- Rename `onReplayResultMapped(...)` to `onReplayResult(...)` and update call sites directly.
- The new name avoids suggesting that a mapping only exists when bookmarks differ.
- This is a breaking SPI change, but the proposal already changes method semantics and custom implementors need to review their implementations.
-
-- Preserve conflict handling unchanged after the first stored observation.
- A repeated notification with the same actual bookmark remains idempotent.
- A repeated notification with a different actual bookmark still follows the configured conflict policy and keeps the original actual bookmark.
-
-## Risks / Trade-offs
-
-- [Risk] Custom `CommandReplayMappingListener` implementations will fail to compile after the rename.
- → Mitigation: Mark the proposal as breaking and update all repository implementations and tests in the same change.
-- [Risk] Persisting identity results increases the number of rows shown by replay result mapping list actions.
- → Mitigation: This is intentional for the upcoming UI requirement, and no schema change is required.
-- [Risk] Code or docs may still use mapping terminology after the rename.
- → Mitigation: Search for old method names and update comments, tests, and relevant specs during implementation.
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/proposal.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/proposal.md
deleted file mode 100644
index 4e79ec43ecc..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The replay mapping SPI currently names its responsibilities around remapping and mapped results, even though replay must now surface every encountered result bookmark for downstream UI and persistence workflows.
-Recording only non-identity result mappings hides replayed objects whose recorded and actual bookmarks are the same, which prevents the ReplayableCommand UI from showing the complete set of involved objects.
-
-## What Changes
-
-- **BREAKING**: Rename `CommandReplayMappingListener#remap(...)` to `lookup(...)` to reflect that listeners look up a previously observed bookmark rather than necessarily remapping it.
-- **BREAKING**: Rename `CommandReplayMappingListener#onReplayResultMapped(...)` to `onReplayResult(...)` to reflect that listeners are notified for every available replay result bookmark pair, including identity results.
-- Update the in-memory replay mapping listener to record every replay result notification keyed by recorded result bookmark, including equal recorded and actual bookmarks.
-- Update the persistent replay mapping listener to persist every replay result notification keyed by recorded result bookmark, including equal recorded and actual bookmarks.
-- Preserve existing conflict handling when a recorded result bookmark is later associated with a different actual result bookmark.
-- Update replay execution and tests to call the renamed SPI methods.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `command-replay-result-mapping`: Rename the SPI methods and clarify that result notifications represent all replay results rather than only non-identity mappings.
-- `default-command-replay-mapping-listener`: Change the built-in in-memory listener so identity replay results are stored and can be looked up later.
-- `persistent-command-replay-mapping-listener`: Change the persistent listener so identity replay results are persisted and can be listed or looked up later.
-
-## Impact
-
-- Affects the command log applib SPI `CommandReplayMappingListener` and all implementations.
-- Affects replay execution code in `ReplayableCommand` that consults listeners before execution and notifies them after successful replay.
-- Affects in-memory and persistent replay mapping listener tests, replay mapping tests, and any downstream custom listener implementations because the SPI method names change.
-- Does not introduce new dependencies or storage tables, but changes persistent listener semantics so identity mappings are saved in the existing replay result mapping repository.
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 348bd325e8b..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,79 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replay mapping SPI can remap command targets before execution
-The system SHALL ask the command replay mapping SPI's common lookup method whether each replayed command target bookmark has a replacement before command execution.
-When the SPI provides a replacement target bookmark, the system SHALL execute the replayed command using the replacement target identifier.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded target identifier.
-The system SHALL use the same lookup method for command targets and reference action parameters.
-
-#### Scenario: Target bookmark is remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2` from its common lookup method
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:2`
-
-#### Scenario: Target bookmark is not remapped
-- **WHEN** command replay is about to execute a command whose recorded target bookmark is `demoCustomer:1`
-- **AND** no command replay mapping SPI provides a replacement bookmark from its common lookup method
-- **THEN** the system executes the replayed command against target bookmark `demoCustomer:1`
-
-### Requirement: Replay mapping SPI can remap reference action parameters before execution
-The system SHALL ask the command replay mapping SPI's common lookup method whether each replayed action parameter represented as `type: "reference"` with a populated `reference` OID has a replacement before command execution.
-When the SPI provides a replacement reference bookmark, the system SHALL execute the replayed command using the replacement parameter reference.
-When no SPI implementation exists or no replacement is provided, the system SHALL execute the replayed command using the recorded parameter reference.
-The system MUST leave non-reference action parameters unchanged by this reference remapping flow.
-The system MUST NOT require the SPI to receive parameter name or parameter index metadata to remap a reference action parameter.
-
-#### Scenario: Reference action parameter is remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** the command replay mapping SPI returns replacement bookmark `simple.SimpleObject:2` from its common lookup method
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "2"`
-
-#### Scenario: Reference action parameter is not remapped
-- **WHEN** command replay is about to execute an action command with parameter `simpleObject` recorded as `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-- **AND** no command replay mapping SPI provides a replacement bookmark from its common lookup method
-- **THEN** the system executes the replayed command with parameter `simpleObject` set to `reference.type: "simple.SimpleObject"` and `reference.id: "1"`
-
-#### Scenario: Non-reference action parameter is not remapped by reference flow
-- **WHEN** command replay is about to execute an action command with a parameter that is not represented as `type: "reference"`
-- **THEN** the system does not ask the command replay mapping SPI's common lookup method to replace that parameter
-
-### Requirement: Replay result mapping SPI is notified after successful replay
-The system SHALL provide a command replay mapping SPI that applications can implement to receive replay result bookmark observations and provide replay input bookmark lookups.
-After a command replay succeeds, the system SHALL notify the SPI when the imported command log entry has a recorded returned object bookmark and replay execution returns an actual result bookmark.
-The notification SHALL include the recorded returned object bookmark and the actual replay result bookmark.
-The system SHALL notify the SPI even when the recorded returned object bookmark and actual replay result bookmark are equal.
-The system SHALL notify the SPI in the same transaction as replay command execution.
-The system SHALL propagate result notification exceptions so the replayed command execution fails and rolls back.
-
-#### Scenario: Successful replay produces a different result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Successful replay produces the same result bookmark
-- **WHEN** command replay succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:1`
-- **THEN** the system notifies the command replay mapping SPI with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-#### Scenario: Result mapping listener rejects the replay result
-- **WHEN** command replay execution succeeds for an imported command whose recorded result bookmark is `demoInvoice:1`
-- **AND** replay execution returns actual result bookmark `demoInvoice:2`
-- **AND** a command replay mapping SPI throws while handling the result notification
-- **THEN** the replayed command execution fails
-- **AND** the replayed command transaction rolls back
-
-### Requirement: Safe action result mappings can remap later replay inputs
-The system SHALL make replay result observations produced by logged safe action commands available to the same replay input lookup flow used by other replayed commands.
-When a later replayed command target or reference parameter uses a recorded bookmark that was observed by an earlier safe action replay, the system SHALL allow the command replay mapping SPI to replace that recorded bookmark with the actual replay bookmark.
-
-#### Scenario: Later replay command target is remapped from safe action result
-- **GIVEN** replay of a safe action command mapped recorded bookmark `demoCustomer:1` to actual bookmark `demoCustomer:2`
-- **WHEN** replay is about to execute a later command whose recorded target bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2`
-- **THEN** the system executes the later replayed command against target bookmark `demoCustomer:2`
-
-#### Scenario: Later replay command reference parameter is remapped from safe action result
-- **GIVEN** replay of a safe action command mapped recorded bookmark `demoCustomer:1` to actual bookmark `demoCustomer:2`
-- **WHEN** replay is about to execute a later command whose reference parameter bookmark is `demoCustomer:1`
-- **AND** the command replay mapping SPI returns replacement bookmark `demoCustomer:2`
-- **THEN** the system executes the later replayed command with reference parameter bookmark `demoCustomer:2`
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/default-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/default-command-replay-mapping-listener/spec.md
deleted file mode 100644
index 4db28ffa4ba..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/default-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,58 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Default replay mapping listener records result mappings
-The system SHALL provide a default command replay mapping listener that records each replay result by recorded result bookmark.
-When replay notifies the listener with a recorded result bookmark and a different actual result bookmark, the listener SHALL remember the actual bookmark for the recorded bookmark if no mapping already exists.
-When replay notifies the listener with equal recorded and actual result bookmarks, the listener SHALL remember the actual bookmark for the recorded bookmark if no mapping already exists.
-When the same recorded bookmark is notified more than once with the same actual result bookmark, the listener SHALL treat the notification as idempotent.
-When the same recorded bookmark is notified more than once with different actual result bookmarks, the listener SHALL apply its configured conflict policy and MUST NOT replace the remembered actual bookmark.
-The system SHALL default the conflict policy to throwing an exception.
-The system SHALL provide a configuration property that can change the conflict policy to log the conflict and continue.
-
-#### Scenario: Different result mapping is recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener records `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Equal result mapping is recorded
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the default listener records `demoInvoice:1` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Result mapping is repeated with the same actual bookmark
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-- **AND** no exception is thrown
-
-#### Scenario: Result mapping conflict is rejected by default
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener throws an exception
-- **AND** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-#### Scenario: Result mapping conflict is logged and ignored when configured
-- **GIVEN** the default listener conflict policy is configured to log and continue
-- **WHEN** command replay notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the default listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the default listener logs the conflict
-- **AND** no exception is thrown
-- **AND** the default listener keeps `demoInvoice:2` as the actual bookmark for `demoInvoice:1`
-
-### Requirement: Default replay mapping listener remaps from recorded results
-The default command replay mapping listener SHALL return a remembered actual bookmark when replay asks it to look up a recorded bookmark that was previously stored from a replay result notification.
-When no mapping is remembered for the recorded bookmark, the listener SHALL return no replacement.
-The listener SHALL perform lookup without resolving recorded or actual bookmarks to live domain objects.
-
-#### Scenario: Recorded bookmark is remapped from stored mapping
-- **WHEN** the default listener has recorded that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the default listener returns replacement bookmark `demoInvoice:2`
-
-#### Scenario: Identity recorded bookmark is looked up from stored mapping
-- **WHEN** the default listener has recorded that `demoInvoice:1` mapped to actual bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the default listener returns replacement bookmark `demoInvoice:1`
-
-#### Scenario: Unmapped recorded bookmark is not replaced
-- **WHEN** the default listener has no recorded mapping for bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the default listener returns no replacement
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/persistent-command-replay-mapping-listener/spec.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/persistent-command-replay-mapping-listener/spec.md
deleted file mode 100644
index 6570aa94aa7..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/specs/persistent-command-replay-mapping-listener/spec.md
+++ /dev/null
@@ -1,75 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Persistent replay mapping listener records result mappings
-The system SHALL provide a persistent command replay mapping listener that records replay results by recorded result bookmark.
-The persisted mapping SHALL store the recorded bookmark and actual bookmark as bookmark value type properties.
-When replay notifies the persistent listener with equal recorded and actual result bookmarks, the listener SHALL persist a mapping for that notification if no mapping already exists.
-When no mapping exists for a recorded result bookmark, the persistent listener SHALL create a mapping to the actual result bookmark.
-When the same recorded bookmark is notified more than once with the same actual bookmark, the persistent listener SHALL treat the notification as idempotent.
-When the same recorded bookmark is notified more than once with a different actual bookmark, the persistent listener SHALL apply the configured conflict policy and MUST NOT replace the persisted actual bookmark.
-
-#### Scenario: Persistent mapping is recorded
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the system persists a mapping with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:2`
-
-#### Scenario: Equal result mapping is persisted
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:1`
-- **THEN** the system persists a mapping with recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-
-#### Scenario: Repeated persistent mapping is idempotent
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **THEN** the system keeps one persisted mapping from `demoInvoice:1` to `demoInvoice:2`
-- **AND** no exception is thrown
-
-#### Scenario: Persistent mapping conflict is rejected when configured to throw
-- **GIVEN** the replay mapping conflict policy is configured to throw an exception
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the persistent listener throws an exception
-- **AND** the persisted mapping remains from `demoInvoice:1` to `demoInvoice:2`
-
-#### Scenario: Persistent mapping conflict is logged when configured to continue
-- **GIVEN** the replay mapping conflict policy is configured to log and continue
-- **WHEN** command replay notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:2`
-- **AND** command replay later notifies the persistent listener that recorded result bookmark `demoInvoice:1` mapped to actual result bookmark `demoInvoice:3`
-- **THEN** the persistent listener logs the conflict
-- **AND** no exception is thrown
-- **AND** the persisted mapping remains from `demoInvoice:1` to `demoInvoice:2`
-
-### Requirement: Persistent replay mapping listener remaps from persisted mappings
-The persistent command replay mapping listener SHALL return a persisted actual bookmark when replay asks it to look up a recorded bookmark that has a stored mapping.
-When no persisted mapping exists for the recorded bookmark, the listener SHALL return no replacement.
-The persistent listener SHALL perform lookup without resolving recorded or actual bookmarks to live domain objects.
-
-#### Scenario: Recorded bookmark is remapped from persisted mapping
-- **WHEN** the persistent listener has stored that `demoInvoice:1` mapped to actual bookmark `demoInvoice:2`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the persistent listener returns replacement bookmark `demoInvoice:2`
-
-#### Scenario: Identity recorded bookmark is looked up from persisted mapping
-- **WHEN** the persistent listener has stored that `demoInvoice:1` mapped to actual bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the persistent listener returns replacement bookmark `demoInvoice:1`
-
-#### Scenario: Unmapped recorded bookmark is not replaced
-- **WHEN** the persistent listener has no persisted mapping for bookmark `demoInvoice:1`
-- **AND** command replay asks the listener to look up recorded bookmark `demoInvoice:1`
-- **THEN** the persistent listener returns no replacement
-
-### Requirement: Persistent replay mappings are listable from the command log menu
-The system SHALL provide a command log menu action that lists persisted replay result mappings.
-The system SHALL provide fallback layout metadata for the persisted replay result mapping entity.
-The list action SHALL return persisted mappings using the abstract applib repository.
-The listed replay result mappings SHALL include identity replay results where the recorded and actual bookmarks are equal.
-
-#### Scenario: User lists persisted replay mappings
-- **WHEN** a user invokes the command log menu action for replay result mappings
-- **THEN** the system returns the persisted replay result mappings
-- **AND** each mapping displays its recorded and actual bookmarks
-
-#### Scenario: User lists persisted identity replay mappings
-- **WHEN** a persisted replay result mapping has recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
-- **AND** a user invokes the command log menu action for replay result mappings
-- **THEN** the system returns the persisted identity replay result mapping
-- **AND** the mapping displays recorded bookmark `demoInvoice:1` and actual bookmark `demoInvoice:1`
diff --git a/openspec/changes/archive/2026-06-07-record-all-replay-results/tasks.md b/openspec/changes/archive/2026-06-07-record-all-replay-results/tasks.md
deleted file mode 100644
index 8eb0a59e915..00000000000
--- a/openspec/changes/archive/2026-06-07-record-all-replay-results/tasks.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## 1. Rename the CommandReplayMappingListener SPI
-
-- [x] 1.1 Rename `CommandReplayMappingListener#remap(CommandLogEntry, Bookmark)` to `lookup(CommandLogEntry, Bookmark)` and update its JavaDoc to describe bookmark lookup rather than remapping.
-- [x] 1.2 Rename `CommandReplayMappingListener#onReplayResultMapped(Bookmark, Bookmark, CommandLogEntry)` to `onReplayResult(Bookmark, Bookmark, CommandLogEntry)` and update its JavaDoc to describe replay result observation.
-- [x] 1.3 Update all replay execution call sites in `ReplayableCommand` to call `lookup(...)` before execution and `onReplayResult(...)` after successful replay.
-
-## 2. Store every replay result notification
-
-- [x] 2.1 Update `CommandReplayMappingListenerInMemory` so `onReplayResult(...)` stores the first actual bookmark for a recorded result bookmark even when the recorded and actual bookmarks are equal.
-- [x] 2.2 Update `CommandReplayMappingListenerPersistent` so `onReplayResult(...)` persists the first actual bookmark for a recorded result bookmark even when the recorded and actual bookmarks are equal.
-- [x] 2.3 Preserve idempotent repeated notifications and configured conflict handling when an existing recorded bookmark is later notified with a different actual bookmark.
-
-## 3. Update tests and documentation references
-
-- [x] 3.1 Update `ReplayableCommandMappingTest` mocks and verifications to use `lookup(...)` and `onReplayResult(...)`.
-- [x] 3.2 Update in-memory listener tests to expect identity replay results to be stored and returned by `lookup(...)`.
-- [x] 3.3 Update persistent listener tests to expect identity replay results to be persisted and returned by `lookup(...)`.
-- [x] 3.4 Search the command log extension for old method names and update comments, JavaDocs, and test names that refer to `remap(...)` or `onReplayResultMapped(...)`.
-
-## 4. Validate
-
-- [x] 4.1 Run the command log applib tests covering `ReplayableCommandMappingTest`, `CommandReplayMappingListenerInMemoryTest`, and `CommandReplayMappingListenerPersistentTest`.
-- [x] 4.2 Run OpenSpec validation for `record-all-replay-results` and fix any spec or task issues.
diff --git a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/.openspec.yaml b/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/design.md b/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/design.md
deleted file mode 100644
index 9da000315f1..00000000000
--- a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/design.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## Context
-
-`ReplayableCommandParticipant` is a view model row that represents target, reference parameter, and result participants for a replayable command.
-It already stores `owningInteractionId` in its memento so instances can identify the owning replayable command.
-The current participant object view exposes too much technical data directly and does not tailor role-specific fields enough.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Add a derived `replayableCommand` property using the owning interaction id and replay context.
-- Hide `owningInteractionId` while preserving it in the memento.
-- Keep `logicalTypeName` available only in metadata.
-- Add or refine the participant title so rows have a useful human-readable label.
-- Replace the participant fallback layout with a three-column layout that separates identity, recorded-side information, and actual-side information.
-- Hide `target`, `argument`, and `result` except for their matching participant roles.
-
-**Non-Goals:**
-
-- Do not change participant construction or memento format unless required to support the parent link.
-- Do not change participant role names or bookmark mapping semantics.
-- Do not change replay command participant collection ordering.
-- Do not change persistence schema or replay mapping SPI signatures.
-
-## Decisions
-
-- Derive `replayableCommand` from `owningInteractionId` because the participant already carries that identifier and the parent is a view model keyed by interaction id.
-- Hide `owningInteractionId` with property-level metadata instead of removing it because it remains useful for memento reconstruction and parent lookup.
-- Keep `logicalTypeName` in a metadata fieldset because it is technical diagnostic information rather than business identity.
-- Use hide support methods for role-specific object properties so irrelevant fields disappear from object details while the table column order remains stable.
-- Keep the layout in fallback XML so applications without custom layout metadata get the improved default view.
-
-## Risks / Trade-offs
-
-- Parent derivation may need access to `ReplayContext` or another lookup service that is not currently held by the participant → Inject or pass the smallest required collaborator without changing the memento contract.
-- Hiding role-specific properties can make table columns appear sparse differently than object details → Preserve existing column-order metadata and apply role-aware hiding primarily to object details.
-- Adding layout XML can be brittle if component ids do not match property ids exactly → Validate with focused tests and an IntelliJ build.
diff --git a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/proposal.md b/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/proposal.md
deleted file mode 100644
index 8100c81ffe8..00000000000
--- a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/proposal.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## Why
-
-`ReplayableCommandParticipant` currently presents technical identifiers and role-specific object fields without enough layout guidance.
-A clearer title, parent link, and role-aware fallback layout will make participant details easier to inspect from the participants table.
-
-## What Changes
-
-- Add or refine fallback layout metadata for `ReplayableCommandParticipant`.
-- Add a useful title for `ReplayableCommandParticipant` instances.
-- Add a derived `replayableCommand` property that links each participant back to its owning `ReplayableCommand`.
-- Hide `owningInteractionId` from the object view while retaining it as memento data.
-- Expose `logicalTypeName` only in a metadata tab or fieldset.
-- Arrange participant details in three columns.
-- Put `replayableCommand`, `role`, and `parameterName` in a first-column `general` fieldset with width `4`.
-- Put `logicalTypeName` in a `metadata` tab or fieldset in the same first-column tab group.
-- Put `recordedBookmark`, `target`, and `argument` in the second column.
-- Hide `target` unless the participant role is `TARGET`.
-- Hide `argument` unless the participant role is `PARAMETER`.
-- Put `actualBookmark` and `result` in the third column.
-- Hide `result` unless the participant role is `RESULT`.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Refine replayable command participant details layout, title, parent link, and role-specific property visibility.
-
-## Impact
-
-- Affects the command log applib replay participant view model and fallback layout metadata.
-- Affects focused participant layout, title, parent-link, and visibility tests.
-- Does not affect participant derivation, bookmark mapping, replay mapping SPI signatures, or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 51ff7705a44..00000000000
--- a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,63 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The `ReplayableCommandParticipant` view model SHALL provide a human-readable title.
-The `ReplayableCommandParticipant` view model SHALL expose a derived `replayableCommand` property that links to its owning replayable command.
-The participant layout SHALL expose replayable command, role, parameter name, recorded bookmark, target, argument, result, and actual bookmark.
-The participant object view MUST NOT expose `owningInteractionId`.
-The participant object view SHALL expose `logicalTypeName` only in metadata.
-The participant fallback layout SHALL use a first column with width `4`.
-The first column SHALL contain a `general` fieldset with replayable command, role, and parameter name.
-The first column SHALL contain a `metadata` tab or fieldset in the same tab group as `general` with logical type name.
-The second column SHALL contain recorded bookmark, target, and argument.
-The second column SHALL hide target unless the participant role is `TARGET`.
-The second column SHALL hide argument unless the participant role is `PARAMETER`.
-The third column SHALL contain actual bookmark and result.
-The third column SHALL hide result unless the participant role is `RESULT`.
-The participant table column order SHALL expose role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view MUST NOT expose command-level `openTarget`, `openArgument`, or `openResult` actions associated with the participants collection.
-Target, argument, and result inspection and navigation SHALL be available through object-valued links in the participants collection rows.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant identity fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the first column has width `4`
-- **AND** the first column general fieldset displays replayable command, role, and parameter name
-- **AND** the first column metadata tab or fieldset displays logical type name
-- **AND** the participant has a human-readable title
-- **AND** the participant does not display owning interaction id
-
-#### Scenario: User views participant recorded-side fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the second column displays recorded bookmark
-- **AND** the second column displays target only for target participants
-- **AND** the second column displays argument only for parameter participants
-
-#### Scenario: User views participant actual-side fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the third column displays actual bookmark
-- **AND** the third column displays result only for result participants
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User navigates using participant object links
-- **WHEN** a user views a replayable command participant with an available target, argument, or result object
-- **THEN** the user can navigate to that object through the corresponding object-valued participant row link
-
-#### Scenario: User navigates to replayable command from participant
-- **WHEN** a user views a replayable command participant
-- **THEN** the participant exposes a replayable command property linked to the owning replayable command
-
-#### Scenario: User does not see redundant open actions
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the replayable command does not expose command-level `openTarget`, `openArgument`, or `openResult` actions associated with the participants collection
diff --git a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/tasks.md b/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/tasks.md
deleted file mode 100644
index a53acc75e93..00000000000
--- a/openspec/changes/archive/2026-06-07-refine-replayable-command-participant-layout/tasks.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## 1. Participant View Model
-
-- [x] 1.1 Add or refine the `ReplayableCommandParticipant` title.
-- [x] 1.2 Add a derived `replayableCommand` property that links to the owning `ReplayableCommand`.
-- [x] 1.3 Hide `owningInteractionId` from the object view while preserving the memento.
-- [x] 1.4 Ensure `logicalTypeName` is available for metadata display.
-- [x] 1.5 Hide `target` unless role is `TARGET`, hide `argument` unless role is `PARAMETER`, and hide `result` unless role is `RESULT`.
-
-## 2. Layout Metadata
-
-- [x] 2.1 Update `ReplayableCommandParticipant.layout.fallback.xml` with the requested three-column layout.
-- [x] 2.2 Put replayable command, role, and parameter name in a first-column `general` fieldset with width `4`.
-- [x] 2.3 Put logical type name in a `metadata` tab or fieldset in the same first-column tab group.
-- [x] 2.4 Put recorded bookmark, target, and argument in the second column.
-- [x] 2.5 Put actual bookmark and result in the third column.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add focused tests for title, parent link, hidden properties, role-specific visibility, and layout metadata.
-- [x] 3.2 Run the command log applib focused test suite for replayable command mapping.
-- [x] 3.3 Run OpenSpec validation for the change.
diff --git a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/.openspec.yaml b/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/design.md b/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/design.md
deleted file mode 100644
index d2d114e8c4c..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/design.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## Context
-
-Synthetic parented collection navigation actions are generated in the metamodel when command-log recording support is enabled.
-The current factory builds the generated action with the parent object type as parameter zero, then appends child filter parameters derived from the associated collection columns.
-That parent parameter is defaulted from the action target and disabled, which means callers cannot use it as true input.
-Command recording already captures the action target separately from action parameters, so the generated command DTO does not need a duplicate parameter for the same object.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Generate synthetic navigate-to actions whose parameters contain only the child filter values needed to identify one collection element.
-- Continue using the action target as the parent object for collection access during validation and invocation.
-- Preserve existing child filter eligibility, naming, ordering, matching, and command result behavior.
-- Update tests and OpenSpec requirements to describe the target-as-context contract.
-
-**Non-Goals:**
-
-- Do not change the synthetic action id prefix, display name, layout association, icon, CSS class, or publishing metadata.
-- Do not change how child filters are selected from collection columns.
-- Do not add compatibility shims for recordings that still include the old disabled parent parameter.
-
-## Decisions
-
-- Remove the parent object from the synthetic action parameter type and name arrays.
- This keeps the metamodel contract aligned with the recording contract, where the target is already represented as the command target.
- Alternative considered: keep the parent parameter hidden instead of disabled.
- That still leaves an extra parameter in command DTOs and replay mappings, so it does not solve the recording noise.
-
-- Pass the action target into navigation matching instead of reading the parent from argument zero.
- Validation and invocation already receive an interaction head or target context, so the implementation should first double-check the available API and then use that target as the parent object while filter arguments are read from index zero onward.
- Alternative considered: synthesize a parent argument internally before calling the existing matcher.
- That would preserve more code but keep confusing index-offset semantics in tests and helper methods.
-
-- Remove parent-parameter-specific facets from synthetic navigation actions.
- Defaults, choices, mandatory, and disabled facets for the old parent parameter become obsolete once the parameter no longer exists.
- Alternative considered: leave the facet classes unused for potential future reuse.
- The implementation can remove unused classes if no other code references them.
-
-## Risks / Trade-offs
-
-- Existing command recordings that include the old first parameter will no longer line up with the generated synthetic action parameter model.
- Mitigation: treat this as a breaking change and update replay fixtures or mappings to omit the duplicate target argument.
-
-- Matching code must be carefully re-indexed so the first filter parameter is not skipped.
- Mitigation: add focused tests asserting parameter ids and validation/invocation behavior with filter arguments starting at index zero.
-
-- Direct tests or tooling may have assumed a mandatory disabled parameter exists.
- Mitigation: update assertions to verify that no parent parameter exists and that the action still uses the target object for collection access.
diff --git a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/proposal.md b/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/proposal.md
deleted file mode 100644
index 88fe17d6aa6..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/proposal.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Why
-
-Synthetic parented collection navigation actions currently expose the current target as a first, mandatory, disabled parameter.
-For command recording support, that target is already implicit in the recorded action target, so serializing it again creates unnecessary noise and a less natural replay contract.
-
-## What Changes
-
-- Remove the synthetic navigation action's explicit target parameter from the generated action parameter model.
-- Keep the action target as the source used to access the associated parented collection during validation and invocation.
-- Keep child filter parameters unchanged, including column-based selection, ordering, and matching semantics.
-- **BREAKING**: Existing recordings or tests that expect the synthetic navigation action to include the disabled parent parameter will need to omit that parameter.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: The synthetic navigation action parameter contract no longer includes the current target as a mandatory disabled first parameter.
-
-## Impact
-
-- Affects synthetic parented collection action construction in `core/metamodel`.
-- Affects command recording and replay payloads for synthetic navigate-to actions because the parameter list becomes shorter.
-- Affects focused metamodel and command recording tests that assert synthetic action parameters.
diff --git a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index e564360853f..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,92 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Selector actions expose parent and scalar child parameters
-The synthetic selector action MUST NOT define a parameter for the current action target.
-The synthetic selector action SHALL use the current action target as the parent object for collection access.
-The synthetic selector action SHALL define optional parameters for eligible scalar properties of the collection element type that appear as columns of the associated parented collection.
-The synthetic selector action SHALL also define optional parameters for eligible reference properties of the collection element type that appear as columns of the associated parented collection and have a bounded, choices, or autocomplete facet installed.
-A reference property with a bounded referenced type SHALL be considered selectable when the bounded semantics install a non-fallback choices facet for that referenced type.
-A reference property with property choices SHALL be considered selectable when a non-fallback property choices facet is installed on the child property.
-A reference property with property autocomplete SHALL be considered selectable when a non-fallback property autocomplete facet is installed on the child property.
-A reference property with a domain-object autocomplete referenced type SHALL be considered selectable when domain-object autocomplete semantics install a non-fallback autocomplete facet for that referenced type.
-The synthetic selector action SHALL order child filter parameters according to the associated parented collection column order.
-The synthetic selector action MUST NOT automatically create selector parameters for child collections.
-The synthetic selector action MUST NOT automatically create selector parameters for reference properties that do not have a bounded, choices, or autocomplete facet installed.
-The synthetic selector action MUST NOT create selector parameters for blob or clob child properties.
-The synthetic selector action MUST NOT create selector parameters for child properties whose ids are `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`.
-
-#### Scenario: Current target is not exposed as a parameter
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has no mandatory disabled parameter typed as `Lease`
-
-#### Scenario: Current target supplies the parent collection owner
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** synthetic parented collection selector action creation is enabled
-- **WHEN** the framework validates or invokes the selector action on a `Lease` target
-- **THEN** the action accesses `items` from that `Lease` target
-
-#### Scenario: Collection column scalar child properties become optional filters
-- **GIVEN** `Lease.items` renders eligible scalar child properties as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has optional parameters corresponding to those column-backed scalar properties
-
-#### Scenario: Collection column bounded reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the referenced type has bounded semantics that install a choices facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column choices reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the child reference property has a choices facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column autocomplete reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the child reference property has an autocomplete facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Collection column domain-object autocomplete reference child properties become optional filters
-- **GIVEN** `Lease.items` renders an eligible child reference property as a collection column
-- **AND** the referenced type has domain-object autocomplete semantics that install an autocomplete facet
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action has an optional parameter corresponding to that column-backed reference property
-
-#### Scenario: Scalar child properties that are not collection columns are excluded from automatic filters
-- **GIVEN** `LeaseItem` has an eligible scalar property that is not rendered as a column of `Lease.items`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for that non-column scalar property
-
-#### Scenario: Selectable reference child properties that are not collection columns are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a selectable reference property that is not rendered as a column of `Lease.items`
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for that non-column reference property
-
-#### Scenario: Child filter parameters follow collection column order
-- **GIVEN** `Lease.items` renders eligible scalar and selectable reference child properties as columns in a configured order
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action lists child filter parameters in the same relative order as the collection columns
-
-#### Scenario: Non-scalar child collections are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a child collection that appears as a collection column
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for the child collection
-
-#### Scenario: Unconstrained reference child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has a reference property that appears as a collection column
-- **AND** the reference property has no bounded, choices, or autocomplete facet installed
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create an automatic parameter for the reference property
-
-#### Scenario: Blob and clob child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has blob and clob properties that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for the blob or clob properties
-
-#### Scenario: Technical metadata child properties are excluded from automatic filters
-- **GIVEN** `LeaseItem` has scalar or reference properties named `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, and `datanucleusVersionTimestamp` that appear as collection columns
-- **WHEN** the framework synthesizes the selector action for `Lease.items`
-- **THEN** the action does not create automatic parameters for `logicalTypeName`, `id`, `version`, `objectIdentifier`, `datanucleusVersionLong`, or `datanucleusVersionTimestamp`
diff --git a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/tasks.md b/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/tasks.md
deleted file mode 100644
index 0e145ab067c..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-navigate-synthetic-target-param/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. Synthetic Action Parameter Model
-
-- [x] 1.1 Update synthetic navigation action parameter type and name creation to omit the parent target parameter.
-- [x] 1.2 Remove installation of parent-parameter defaults, choices, mandatory, and disabled facets from generated navigation actions.
-- [x] 1.3 Remove unused parent-parameter facet classes and imports if no remaining code references them.
-
-## 2. Validation and Invocation Semantics
-
-- [x] 2.1 Double-check the validation and invocation APIs expose the current action target reliably enough to use as the parent collection owner.
-- [x] 2.2 Refactor navigation matching to use the action target as the parent collection owner.
-- [x] 2.3 Re-index child filter matching so filter arguments start at parameter index zero.
-- [x] 2.4 Preserve no-match, ambiguous-match, partial-string, reference equality, and command result behavior after removing the parent argument.
-
-## 3. Tests and Verification
-
-- [x] 3.1 Update metamodel tests to assert that synthetic navigate-to actions do not expose a parent target parameter.
-- [x] 3.2 Update validation, invocation, and command publishing tests to pass only child filter arguments.
-- [x] 3.3 Run focused `ParentedCollectionNavigationActionUtilTest` coverage for the synthetic navigation action changes.
-- [x] 3.4 Run OpenSpec validation for `remove-navigate-synthetic-target-param`.
diff --git a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/.openspec.yaml b/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/design.md b/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/design.md
deleted file mode 100644
index f14d15d906b..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/design.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Context
-
-`ReplayableCommand` currently exposes the participants collection and command-level `openTarget`, `openArgument`, and `openResult` actions associated with that collection.
-Each participant row already exposes object-valued target, argument, and result properties.
-In the UI, those object-valued properties can be followed directly from the participant row, making the command-level open actions redundant.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Remove `ReplayableCommand_openTarget`, `ReplayableCommand_openArgument`, and `ReplayableCommand_openResult`.
-- Remove the corresponding module imports and registrations.
-- Remove tests that verify the redundant open actions.
-- Update the participant UI spec to rely on participant row links for navigation.
-
-**Non-Goals:**
-
-- Do not remove the participants collection.
-- Do not remove target, argument, result, recorded bookmark, actual bookmark, or parameter name participant properties.
-- Do not change participant derivation, object lookup, replay mapping semantics, or replay state behaviour.
-- Do not change persistence schema or replay mapping SPI signatures.
-
-## Decisions
-
-- Delete the mixin classes rather than hiding or deprecating them because the actions were introduced only as recent refinements and are now intentionally superseded by direct participant-row navigation.
-- Keep object-valued participant properties unchanged so end-users can still open linked target, argument, and result objects from the table.
-- Update tests by removing action-specific cases while preserving participant resolution tests that prove the linked objects remain available.
-
-## Risks / Trade-offs
-
-- Consumers that automated calls to the action mixins will need to navigate through participant object links instead → Mark the removal as breaking in the proposal.
-- Removing action tests could reduce coverage of object lookup → Keep and rely on participant object resolution tests for target, argument, and result properties.
diff --git a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/proposal.md b/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/proposal.md
deleted file mode 100644
index 3dc9df738d1..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The participants table already exposes target, argument, and result participant objects as navigable links.
-The separate `openTarget`, `openArgument`, and `openResult` command actions duplicate that built-in navigation and add unnecessary UI complexity.
-
-## What Changes
-
-- Remove the `ReplayableCommand_openTarget` mixin.
-- Remove the `ReplayableCommand_openArgument` mixin.
-- Remove the `ReplayableCommand_openResult` mixin.
-- Remove module registrations and tests for those mixins.
-- Keep the participants collection and participant row properties unchanged.
-- **BREAKING**: Consumers invoking the command-level `openTarget`, `openArgument`, or `openResult` actions must navigate through the participant row links instead.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Remove the participants-associated open actions and rely on participant row links for target, argument, and result navigation.
-
-## Impact
-
-- Affects the command log applib replay UI mixin set and module registration.
-- Affects focused replayable command participant navigation tests.
-- Does not affect participant derivation, bookmark mapping, replay mapping SPI signatures, or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index c8507d1fd2f..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view MUST NOT expose command-level `openTarget`, `openArgument`, or `openResult` actions associated with the participants collection.
-Target, argument, and result inspection and navigation SHALL be available through object-valued links in the participants collection rows.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User navigates using participant object links
-- **WHEN** a user views a replayable command participant with an available target, argument, or result object
-- **THEN** the user can navigate to that object through the corresponding object-valued participant row link
-
-#### Scenario: User does not see redundant open actions
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the replayable command does not expose command-level `openTarget`, `openArgument`, or `openResult` actions associated with the participants collection
diff --git a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/tasks.md b/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/tasks.md
deleted file mode 100644
index c640b3f31a2..00000000000
--- a/openspec/changes/archive/2026-06-07-remove-replayable-command-open-participant-actions/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Remove Open Action Mixins
-
-- [x] 1.1 Delete the `ReplayableCommand_openTarget` mixin class.
-- [x] 1.2 Delete the `ReplayableCommand_openArgument` mixin class.
-- [x] 1.3 Delete the `ReplayableCommand_openResult` mixin class.
-- [x] 1.4 Remove the deleted mixins from command log applib module imports and registrations.
-
-## 2. Tests
-
-- [x] 2.1 Remove focused tests for `openTarget`, `openArgument`, and `openResult` action metadata and behaviour.
-- [x] 2.2 Ensure participant object resolution tests still cover target, argument, and result object availability through participant rows.
-
-## 3. Validation
-
-- [x] 3.1 Run the command log applib focused test suite for replayable command mapping.
-- [x] 3.2 Run OpenSpec validation for the change.
diff --git a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/.openspec.yaml b/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/design.md b/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/design.md
deleted file mode 100644
index de0e0947bb2..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/design.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## Context
-
-`ReplayableCommandParticipant` currently models participant rows for target, reference parameter, and result bookmarks.
-The row already has a `parameterName` property that identifies the recorded command parameter.
-It also exposes a `parameter` object-valued property for the resolved actual reference parameter object.
-Using both `parameterName` and `parameter` makes the UI and API terminology less clear because one is metadata and the other is the resolved replay argument.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Rename the object-valued participant property from `parameter` to `argument`.
-- Preserve `parameterName` exactly as the recorded command parameter label.
-- Keep participant derivation, bookmark mapping, and object resolution behaviour unchanged.
-- Update fallback layout metadata and tests to use the new property name.
-
-**Non-Goals:**
-
-- Do not rename the participant role `PARAMETER`.
-- Do not rename `parameterName`.
-- Do not change command DTO parsing, replay mapping SPI signatures, or persistence schema.
-- Do not introduce compatibility aliases unless implementation constraints require them.
-
-## Decisions
-
-- Use `argument` as the object-valued property name because it describes the runtime value supplied to the replayed command while avoiding collision with `parameterName`.
-- Keep the participant role and recorded parameter metadata unchanged because they describe the command signature and existing replay semantics.
-- Update layout and column-order metadata in the same change so UI rendering and fallback table ordering stay aligned with the renamed property.
-- Treat this as a source/API-breaking rename for consumers of `ReplayableCommandParticipant#parameter`, rather than adding a deprecated duplicate property, because the command log applib participant type is newly introduced and the requested refinement is terminology cleanup.
-
-## Risks / Trade-offs
-
-- Existing custom code or layouts referencing `parameter` will fail until updated → Mark the change as breaking in the proposal and update all in-repository references.
-- Display labels may still mention reference parameters through `parameterName` and role `PARAMETER` → Preserve that wording intentionally because it identifies the command parameter, not the resolved argument object.
-- Tests could miss layout metadata regressions → Update focused participant tests to assert the new `argument` property and column ordering.
diff --git a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/proposal.md b/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/proposal.md
deleted file mode 100644
index 3652094acf6..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The replayable command participants UI currently exposes a reference parameter object through a property named `parameter`, which is easy to confuse with the existing `parameterName` metadata.
-Renaming the object-valued property to `argument` makes the row model clearer while preserving `parameterName` as the recorded command parameter label.
-
-## What Changes
-
-- Rename the `ReplayableCommandParticipant` object-valued `parameter` property to `argument`.
-- Update participant layout and column-order metadata so target, argument, and result object columns appear in the intended order.
-- Update tests and any references that expect the old `parameter` property name.
-- Preserve the `parameterName` property and its behaviour unchanged.
-- **BREAKING**: Consumers using the `ReplayableCommandParticipant#parameter` property must switch to `argument`.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Rename the reference parameter object property exposed by replayable command participants from `parameter` to `argument` while preserving `parameterName`.
-
-## Impact
-
-- Affects the command log applib replay view model `ReplayableCommandParticipant`.
-- Affects fallback layout and column-order metadata for replayable command participants.
-- Affects focused tests that assert participant property names and layout order.
-- Does not affect replay mapping SPI signatures or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 6f1b3439054..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,137 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable command displays command participants
-The system SHALL expose a participants collection on each replayable command.
-The participants collection SHALL contain rows represented by `ReplayableCommandParticipant` view models.
-Each participant SHALL expose the role, parameter name, recorded bookmark, target object, argument object, result object, and actual bookmark in that order.
-The system SHALL include target participants when the command DTO has recorded target bookmarks.
-The system SHALL include reference parameter participants when the command DTO has recorded reference parameter bookmarks.
-The system MUST NOT include non-reference parameters as bookmark participants.
-The system SHALL include a result participant when the recorded command has a recorded result bookmark.
-Each included participant SHALL expose its recorded bookmark.
-Target participants SHALL expose an actual bookmark whenever replay mapping lookup provides a mapped bookmark.
-Reference parameter participants SHALL expose an actual bookmark whenever replay mapping lookup provides a mapped bookmark.
-Target and reference parameter participants SHALL leave actual bookmarks empty before successful replay when replay mapping lookup provides no mapped bookmark.
-Target and reference parameter participants SHALL use their recorded bookmark as the actual bookmark after successful replay when replay mapping lookup provides no mapped bookmark.
-Result participants SHALL expose actual bookmarks only after the replayable command has successfully replayed.
-When a successful replay has no explicit replacement bookmark for a result participant, the participant SHALL use its recorded bookmark as the actual bookmark.
-
-#### Scenario: Target participant appears in replayable command details
-- **WHEN** a replayable command has recorded target bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `TARGET`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Reference parameter participant appears in replayable command details
-- **WHEN** a replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `PARAMETER`
-- **AND** the participant has parameter name `customer`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Non-reference parameter is omitted
-- **WHEN** a replayable command has parameter `name` recorded as a string value
-- **THEN** the replayable command participants collection does not contain a participant for parameter `name`
-
-#### Scenario: Pending command populates mapped target actual bookmark
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the target participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Pending command populates mapped parameter actual bookmark
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the parameter participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Pending command leaves unmapped target actual bookmark empty
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the target participant has no actual bookmark
-
-#### Scenario: Pending command leaves unmapped parameter actual bookmark empty
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the parameter participant has no actual bookmark
-
-#### Scenario: Successful replay populates mapped target actual bookmark
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the target participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Successful replay keeps unchanged target actual bookmark populated
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the target participant has actual bookmark `demoCustomer:1`
-
-#### Scenario: Successful replay keeps unchanged parameter actual bookmark populated
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the parameter participant has actual bookmark `demoCustomer:1`
-
-### Requirement: Replayable command participant resolves target, parameter, and result objects best-effort
-The `ReplayableCommandParticipant` view model SHALL expose a target object for target participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL expose an argument object for parameter participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL expose a result object for result participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL still expose recorded and actual bookmark values when the actual bookmark cannot be resolved locally.
-The system MUST NOT require recorded bookmarks to resolve locally in order to display a participant.
-
-#### Scenario: Target participant resolves actual object
-- **WHEN** a target participant has actual bookmark `demoCustomer:2`
-- **AND** bookmark lookup resolves `demoCustomer:2` to a local domain object
-- **THEN** the participant target property exposes that local domain object
-- **AND** the participant still displays recorded bookmark `demoCustomer:1`
-- **AND** the participant still displays actual bookmark `demoCustomer:2`
-
-#### Scenario: Parameter participant resolves actual object
-- **WHEN** a parameter participant has actual bookmark `demoCustomer:2`
-- **AND** bookmark lookup resolves `demoCustomer:2` to a local domain object
-- **THEN** the participant argument property exposes that local domain object
-- **AND** the participant still displays recorded bookmark `demoCustomer:1`
-- **AND** the participant still displays actual bookmark `demoCustomer:2`
-
-#### Scenario: Parameter participant keeps unresolved bookmark values
-- **WHEN** a reference parameter participant has actual bookmark `external.Customer:2`
-- **AND** bookmark lookup cannot resolve `external.Customer:2` to a local domain object
-- **THEN** the participant argument property is empty
-- **AND** the participant still displays recorded bookmark `external.Customer:1`
-- **AND** the participant still displays actual bookmark `external.Customer:2`
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view SHALL expose an `openTarget` action associated with the participants collection.
-The `openTarget` action SHALL have layout sequence `1`.
-The `openTarget` action SHALL open the actual target object when a target participant has an actual target available.
-The `openTarget` action SHALL be disabled when no actual target object is available.
-Target inspection and navigation SHALL be available through target rows in the participants collection.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, argument, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User opens actual target from participants action
-- **WHEN** a replayable command target participant has an actual target object available
-- **THEN** the replayable command exposes an `openTarget` action associated with the participants collection
-- **AND** the `openTarget` action has layout sequence `1`
-- **AND** invoking the action opens the actual target object
-
-#### Scenario: User cannot open target without actual target
-- **WHEN** a replayable command has no target participant actual target object available
-- **THEN** the `openTarget` action is disabled
diff --git a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/tasks.md b/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/tasks.md
deleted file mode 100644
index 86bcd9f2f94..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-replayable-command-participant-parameter/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. Participant API Rename
-
-- [x] 1.1 Rename the `ReplayableCommandParticipant` object-valued `parameter` property to `argument` while leaving `parameterName` unchanged.
-- [x] 1.2 Update participant construction and object lookup code so parameter participants expose resolved objects through `argument`.
-- [x] 1.3 Remove or update in-repository references to the old `parameter` property name.
-
-## 2. Layout Metadata
-
-- [x] 2.1 Update fallback column order metadata to use `argument` between `target` and `result`.
-- [x] 2.2 Update any fallback layout metadata or property names that reference `parameter` as the object-valued participant property.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Update focused replayable command participant tests to assert `argument` and preserve `parameterName`.
-- [x] 3.2 Run the command log applib focused test suite for replayable command mapping.
-- [x] 3.3 Run OpenSpec validation for the change.
diff --git a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/.openspec.yaml b/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/design.md b/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/design.md
deleted file mode 100644
index 50c9d78505e..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/design.md
+++ /dev/null
@@ -1,68 +0,0 @@
-## Context
-
-Synthetic parented collection actions are generated in `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil` when command-log recording support is enabled.
-They currently use select-oriented terminology in their deterministic action id prefix, user-facing display name, facet class names, tests, and documentation.
-The action behavior is navigation from a parent object to one child object, and command recording identifies the action by its action id in command DTO payloads.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Make the generated action contract use navigation terminology by exposing `Navigate To` as the display name.
-- Make new command recordings use a deterministic `__causeway_navigate_to_<collectionId>` action id.
-- Rename implementation symbols where practical so future command recording navigation enhancements do not inherit select-specific terminology.
-- Preserve the existing metamodel behavior other than naming, including action safety, collection association, styling, parameter generation, validation, invocation, command publishing, and empty-collection disabling.
-
-**Non-Goals:**
-
-- Do not add compatibility aliases that register both the old and new synthetic action ids in the metamodel.
-- Do not change command export, replay, or remapping formats beyond the action id emitted for newly recorded synthetic navigation commands.
-- Do not change matching semantics for scalar or reference filter parameters.
-- Do not add new configuration properties for naming or compatibility.
-
-## Decisions
-
-### Rename the canonical action id prefix
-
-The synthetic action factory should replace `__causeway_select_from_` with `__causeway_navigate_to_` as the canonical reserved prefix.
-This makes the command DTO action id describe the recorded navigation step rather than the current UI affordance.
-
-Alternative considered: keep the existing action id and only rename the display name.
-That would avoid a command DTO break, but it would leave command recordings and replay diagnostics tied to the old select terminology and would not establish a generic namespace for future navigation commands.
-
-Alternative considered: generate both action ids as aliases.
-That would soften migration, but it would duplicate metamodel actions or require a replay-only lookup special case and could make ordinary action enumeration ambiguous.
-
-### Rename the user-facing action name to `Navigate To`
-
-The member-name facet installed on the synthetic action should use `Navigate To` instead of `Select`.
-This keeps the viewer label aligned with the action's purpose and with the new action id prefix.
-
-Alternative considered: use `Navigate`.
-`Navigate To` is slightly longer, but it reads naturally as an action associated with a collection and a target child row.
-
-### Keep the capability name and external concept stable for this change
-
-The OpenSpec capability remains `parented-collection-selector-actions` because the capability still covers the existing generated action feature and its matching/filtering semantics.
-Implementation can rename symbols from selector to navigation where the symbol identifies the synthetic action, while utility code that specifically filters or selects a child row can retain selector-oriented helper names if a full rename would obscure behavior.
-
-Alternative considered: introduce a new `parented-collection-navigation-actions` capability and remove the old one.
-That would overstate the scope because this change is a rename of an existing requirement rather than a replacement of the feature.
-
-## Risks / Trade-offs
-
-- Existing recorded command DTOs reference the old action id prefix → Users must migrate recordings, re-record commands, or configure replay remapping from `__causeway_select_from_<collectionId>` to `__causeway_navigate_to_<collectionId>`.
-- Partial renaming can leave mixed implementation terminology → Tests and review should cover public constants, class names, test names, and user-facing strings most likely to affect future maintainers.
-- Downstream code may have assertions against `Select` or `__causeway_select_from_` → The break is intentional and should be highlighted in release notes or migration notes if this branch publishes them.
-- Generated action ids remain collection-id-based → This preserves deterministic lookup but still depends on stable collection ids, matching the existing behavior.
-
-## Migration Plan
-
-- Update metamodel generation to emit only the new display name and action id prefix.
-- Update tests to assert the new values and to remove old select-oriented expectations.
-- For existing recordings, migrate serialized command DTO action ids or add replay remapping data outside this change when old recordings must continue to replay.
-- Rollback is possible by restoring the old prefix and display name before release, but recordings created during the interim would then need the inverse migration.
-
-## Open Questions
-
-- Should archive/release notes explicitly include the command DTO action id migration recipe when this change is implemented?
diff --git a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/proposal.md b/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/proposal.md
deleted file mode 100644
index 0e904659bd4..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The synthetic parented collection action currently uses “select” naming even though its behavior is navigation from an owner object to a child object.
-Renaming the action contract to “navigate to” makes command recording terminology more generic and creates room for future recorded navigation enhancements beyond collection row selection.
-
-## What Changes
-
-- Rename the synthetic parented collection action display name from `Select` to `Navigate To`.
-- Rename the deterministic synthetic action identifier prefix from `__causeway_select_from_` to `__causeway_navigate_to_`.
-- Rename selector-focused implementation types, facet names, constants, and tests to use navigation terminology where they describe the synthetic action itself.
-- Preserve the action's existing creation gating, collection association, styling, parameters, validation, invocation, command publishing, and result behavior.
-- **BREAKING**: Previously recorded command DTOs that reference `__causeway_select_from_<collectionId>` will no longer match the generated synthetic action id unless they are migrated or remapped to `__causeway_navigate_to_<collectionId>`.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `parented-collection-selector-actions`: The synthetic action's user-facing name and deterministic command action id change from select-oriented terminology to navigate-oriented terminology.
-
-## Impact
-
-- Affects synthetic parented collection action creation in `core/metamodel`, especially `ObjectSpecificationAbstract.ParentedCollectionSelectorActionUtil` and related synthetic action facets.
-- Affects metamodel tests for synthetic parented collection actions and any tests asserting the reserved action id prefix or display name.
-- Affects command recording, export, and replay payloads that identify these synthetic actions by action id.
-- Does not add dependencies or change ordinary collection browsing behavior.
diff --git a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/specs/parented-collection-selector-actions/spec.md b/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/specs/parented-collection-selector-actions/spec.md
deleted file mode 100644
index 89443a54a43..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/specs/parented-collection-selector-actions/spec.md
+++ /dev/null
@@ -1,94 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Framework synthesizes selector actions for parented collections
-The system SHALL provide the `causeway.extensions.command-log.recording-support` configuration property that controls command-log recording support behavior.
-The `recording-support` property SHALL be an enum with values `ENABLED` and `DISABLED`.
-The system SHALL default `recording-support` to `DISABLED`.
-When `recording-support` is `ENABLED`, the system SHALL synthesize a safe metamodel `ObjectAction` for each eligible parented collection association whose owning type does not implement the command recording suppression marker interface.
-When `recording-support` is `DISABLED`, the system MUST NOT synthesize parented collection selector actions.
-When a parented collection association's owning type implements the command recording suppression marker interface, the system MUST NOT synthesize a parented collection selector action for that association.
-The system MUST NOT require or use a separate `causeway.extensions.command-log.parented-collection-selector-actions-enabled` boolean property to enable synthetic parented collection selector action creation.
-An eligible parented collection association SHALL be allowed when its owning type is an entity or view model and its element type is an entity, view model, or abstract domain type.
-The synthetic action SHALL represent navigation from the collection owner to one selected collection element.
-The synthetic action SHALL have a deterministic identifier that does not collide with developer-authored actions.
-The synthetic action identifier SHALL use the reserved prefix `__causeway_navigate_to_` followed by the associated parented collection id.
-The synthetic action SHALL be distinguishable from developer-authored actions by framework metadata.
-The synthetic action SHALL be associated with the parented collection through layout metadata equivalent to `@ActionLayout(associateWith=...)`.
-The synthetic action SHALL have the display name `Navigate To` through name metadata equivalent to `@ActionLayout(named="Navigate To")`.
-The synthetic action SHALL have action layout CSS class metadata equivalent to `@ActionLayout(cssClass="btn-outline-secondary")`.
-The synthetic action SHALL have action layout Font Awesome metadata equivalent to `@ActionLayout(cssClassFa="hand-point-left")`.
-
-#### Scenario: Synthetic action is not available by default
-- **GIVEN** a domain object type has a parented collection of child entities
-- **AND** command-log recording support is not configured
-- **WHEN** the framework fully introspects the domain object type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is available when recording support is enabled for an entity-owned parented collection
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **AND** the entity type does not implement the command recording suppression marker interface
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel includes a synthetic safe action for navigating to one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action is available when recording support is enabled for a view-model-owned parented collection
-- **GIVEN** a view model type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **AND** the view model type does not implement the command recording suppression marker interface
-- **WHEN** the framework fully introspects the view model type
-- **THEN** the metamodel includes a synthetic safe action for navigating to one element from that collection
-- **AND** the synthetic action is associated with the collection owner type
-
-#### Scenario: Synthetic action is not added for marked entity type
-- **GIVEN** an entity type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **AND** the entity type implements the command recording suppression marker interface
-- **WHEN** the framework fully introspects the entity type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action is not added for marked view model type
-- **GIVEN** a view model type has a parented collection of child entities
-- **AND** command-log recording support is `ENABLED`
-- **AND** the view model type implements the command recording suppression marker interface
-- **WHEN** the framework fully introspects the view model type
-- **THEN** the metamodel does not include a synthetic selector action for that collection
-
-#### Scenario: Synthetic action id is deterministic
-- **GIVEN** the framework introspects the same parented collection in two application runs
-- **WHEN** the synthetic selector action is created in each run
-- **THEN** both actions have the same action identifier
-- **AND** the identifier uses the reserved prefix `__causeway_navigate_to_`
-- **AND** the identifier is reserved so it does not conflict with application action ids
-
-#### Scenario: Ordinary action lists can identify synthetic actions
-- **WHEN** a viewer or metamodel exporter enumerates actions for a type
-- **THEN** it can determine whether a listed action is a synthetic parented collection selector action
-
-#### Scenario: Synthetic action is associated with its parented collection
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **AND** `Lease` does not implement the command recording suppression marker interface
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has layout association metadata for collection id `items`
-
-#### Scenario: Synthetic action display name is Navigate To
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **AND** `Lease` does not implement the command recording suppression marker interface
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action display name is `Navigate To`
-
-#### Scenario: Synthetic action uses secondary button styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **AND** `Lease` does not implement the command recording suppression marker interface
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has CSS class metadata of `btn-outline-secondary`
-
-#### Scenario: Synthetic action uses select navigation icon styling
-- **GIVEN** an entity type `Lease` has a parented collection `items`
-- **AND** command-log recording support is `ENABLED`
-- **AND** `Lease` does not implement the command recording suppression marker interface
-- **WHEN** the framework synthesizes the selector action for `items`
-- **THEN** the action has Font Awesome metadata of `hand-point-left`
diff --git a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/tasks.md b/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/tasks.md
deleted file mode 100644
index 8cab4ed9f71..00000000000
--- a/openspec/changes/archive/2026-06-07-rename-select-synthetic-action-to-navigate/tasks.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 1. Synthetic Action Naming
-
-- [x] 1.1 Rename the synthetic action id prefix from `__causeway_select_from_` to `__causeway_navigate_to_` in the parented collection synthetic action factory.
-- [x] 1.2 Rename the synthetic action display name from `Select` to `Navigate To` in the member-name facet installation.
-- [x] 1.3 Rename implementation symbols, constants, facet classes, and helper names from selector terminology to navigation terminology where they describe the synthetic action contract.
-- [x] 1.4 Preserve existing creation gating, collection association, styling, command publishing, parameter generation, validation, invocation, and empty-collection disabling behavior.
-
-## 2. Command Recording Compatibility Notes
-
-- [x] 2.1 Identify tests or fixtures that assert command DTO action ids for synthetic collection navigation and update them to the new `__causeway_navigate_to_` prefix.
-- [x] 2.2 Add or update migration documentation or release-note text if the project has an appropriate location for command DTO action id breaking changes.
-
-## 3. Test Coverage
-
-- [x] 3.1 Update metamodel tests to assert that synthetic parented collection actions use the `__causeway_navigate_to_` reserved prefix.
-- [x] 3.2 Update metamodel tests to assert that synthetic parented collection actions expose display name `Navigate To`.
-- [x] 3.3 Update any renamed class or method test references so focused tests still cover generated actions for normal, mixed-in, entity-owned, and view-model-owned parented collections.
-- [x] 3.4 Run the focused `ParentedCollectionSelectorActionUtilTest` Maven test set or its renamed equivalent.
-- [x] 3.5 Run `openspec validate rename-select-synthetic-action-to-navigate --strict` and fix any proposal, spec, design, or task validation issues.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/.openspec.yaml b/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/design.md b/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/design.md
deleted file mode 100644
index c111c20fc8c..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/design.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Context
-
-`ReplayableCommand` originally exposed `targetType`, `targetId`, and `openTarget` so users could identify and navigate the recorded command target.
-The newer `Participants` collection exposes target participants with recorded bookmark, actual bookmark, and resolved target object support.
-Keeping both presentations duplicates target information and creates a less focused page.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Remove the legacy target summary properties from the replayable command view model.
-- Remove the legacy target navigation action from the replayable command view model.
-- Update fallback layout metadata so the Target field set no longer references removed members.
-- Keep target inspection and navigation available through the `Participants` table.
-
-**Non-Goals:**
-
-- Do not change participant row derivation.
-- Do not change replay mapping lookup or result notification behaviour.
-- Do not change command DTO rendering or replay execution.
-- Do not introduce persistence or schema changes.
-
-## Decisions
-
-### Remove members instead of hiding them
-
-The target summary members should be removed from `ReplayableCommand` rather than only hidden in fallback layout metadata.
-This avoids maintaining duplicate APIs for a cosmetic view and prevents unreferenced members from appearing in generated or custom layouts.
-The alternative was to hide only the fallback layout entries, but that would still leave the properties and action available to the metamodel.
-
-### Leave title member derivation intact unless it depends on removed properties
-
-`ReplayableCommand.title()` may continue to summarize the command using command DTO data if it remains useful for lists and breadcrumbs.
-If implementation requires helper methods to replace removed getters, those helpers should be programmatic and not exposed as properties.
-The alternative was to remove all target data from the title, but that would reduce object identification outside the participants table.
-
-### Keep participant table unchanged
-
-The participants collection already provides the replacement target inspection surface.
-This change should not alter its rows, column order, object lookup, or bookmark population behaviour.
-The alternative was to further redesign participants, but that would expand a cosmetic cleanup into a behaviour change.
-
-## Risks / Trade-offs
-
-- [Risk] Custom layouts or tests may reference the removed target members.
- → Mitigate by updating fallback layout and focused tests, and by treating the removal as an intentional UI cleanup.
-- [Risk] Removing `openTarget` changes a direct navigation affordance.
- → Mitigate by relying on participant target object links, which now carry the same target information with bookmark context.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/proposal.md b/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/proposal.md
deleted file mode 100644
index 383f0cca9c7..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-`ReplayableCommand` now shows target, parameter, and result information through the `Participants` table.
-The older target summary fields and `openTarget` action duplicate that information and make the page busier than necessary.
-
-## What Changes
-
-- Remove the `targetType` and `targetId` properties from `ReplayableCommand`.
-- Remove the `openTarget` action from `ReplayableCommand`.
-- Remove the target field set entries from the `ReplayableCommand` fallback layout.
-- Keep the `Participants` table as the place to inspect and navigate target information.
-- Keep command member, replay state, DTO, and participant behaviour unchanged.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Clarifies that replayable command target inspection is provided through participants, not the legacy target summary properties or action.
-
-## Impact
-
-- Affects `ReplayableCommand` in `extensions/core/commandlog/applib`.
-- Affects `ReplayableCommand.layout.fallback.xml` in the same package.
-- Affects focused command log applib tests if any assert the removed target summary members.
-- No persistence schema, replay mapping SPI, or participant table changes are expected.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 0906e5e7ad1..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view MUST NOT expose a separate open target action.
-Target inspection and navigation SHALL be available through target rows in the participants collection.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** the layout does not display a separate `openTarget` action
-- **AND** target information is available through the participants table
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/tasks.md b/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/tasks.md
deleted file mode 100644
index c1d840ba0a1..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-cosmetics/tasks.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 1. ReplayableCommand Cleanup
-
-- [x] 1.1 Remove the `openTarget` action and its `BookmarkService` dependency from `ReplayableCommand`.
-- [x] 1.2 Remove exposed `targetType` and `targetId` properties from `ReplayableCommand`.
-- [x] 1.3 Preserve any needed title logic using non-exposed helpers if required.
-
-## 2. Layout Metadata
-
-- [x] 2.1 Remove `openTarget`, `targetType`, and `targetId` references from `ReplayableCommand.layout.fallback.xml`.
-- [x] 2.2 Keep the `member`, replay state, DTO, and participants table layout unchanged except for removed target members.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Update focused command log applib tests for the removed target members if needed.
-- [x] 3.2 Run focused command log applib tests for replayable command mapping and participant behaviour.
-- [x] 3.3 Run `openspec validate replayable-command-cosmetics --strict`.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/.openspec.yaml b/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/design.md b/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/design.md
deleted file mode 100644
index e4cc2330fba..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/design.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Context
-
-`ReplayableCommand` recently removed the target summary fields and the old target-opening mixins because participant rows now carry target information.
-The participants table is still the right place for target details, but users benefit from a command-level navigation action that opens the current actual target when that actual target is known and resolvable.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Reintroduce an `openTarget` mixin for `ReplayableCommand`.
-- Associate the action with the `participants` collection using sequence `1`.
-- Resolve the target from the target participant's actual bookmark rather than from legacy target summary fields.
-- Disable the action when there is no actual target available to open.
-
-**Non-Goals:**
-
-- Do not reintroduce `targetType` or `targetId` properties.
-- Do not reintroduce the table-row `openTargetTR` action.
-- Do not change participant row layout, column order, or derivation except as needed to locate the actual target.
-- Do not change replay mapping SPI or replay execution behaviour.
-
-## Decisions
-
-### Use a participants-associated mixin
-
-The action should be associated with the `participants` collection so it appears next to the data that justifies opening the target.
-Using sequence `1` gives predictable placement among collection-associated actions.
-The alternative was to place the action in a separate field set or domain-object action area, but that would weaken the relationship with participant data.
-
-### Open only actual target values
-
-The action should open the target participant's actual target object, not the recorded command target.
-This matches the participant table semantics and avoids reintroducing the older recorded-target navigation behaviour.
-The alternative was to open the command log entry target, but that can point at recorded state rather than the actual replay participant.
-
-### Disable when no actual target is available
-
-The action should be disabled when no target participant actual bookmark exists or when the bookmark cannot resolve to an object.
-This avoids presenting an action that would return null.
-The alternative was to leave the action enabled and return null, but that gives a poor UI signal.
-
-## Risks / Trade-offs
-
-- [Risk] Resolving the actual target during disable checks can perform a bookmark lookup while rendering the page.
- → Mitigate by limiting lookup to the target participant and using best-effort existing bookmark lookup semantics.
-- [Risk] Multiple target participants could exist for a command.
- → Mitigate by using the first target participant, consistent with the existing command title and target handling conventions.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/proposal.md b/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/proposal.md
deleted file mode 100644
index 5ae5976aacb..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/proposal.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## Why
-
-The participants table is now the primary place to inspect replayable command targets, but users still need a convenient action on the command page to open the actual target when one is available.
-Reintroducing `openTarget` as a participants-associated action keeps navigation close to the participant data without restoring the removed target summary fields.
-
-## What Changes
-
-- Reintroduce the `ReplayableCommand_openTarget` mixin.
-- Associate the action with the `participants` collection.
-- Set the action layout sequence to `1`.
-- Open the actual target represented by the target participant.
-- Disable the action when no actual target is available.
-- Do not reintroduce `targetType`, `targetId`, or table-row `openTargetTR` actions.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Refines replayable command target navigation so `openTarget` is available as a participants-associated action only when an actual target can be opened.
-
-## Impact
-
-- Affects `ReplayableCommand` and its mixins in `extensions/core/commandlog/applib`.
-- Affects module imports in `CausewayModuleExtCommandLogApplib`.
-- Affects focused command log applib tests for participant-derived target actuals and action enablement.
-- No persistence schema, replay mapping SPI, or participant table column changes are expected.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index e46e310650b..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants` before the control field set.
-The `ReplayableCommand` object view MUST NOT expose separate target summary properties for target type or target identifier.
-The `ReplayableCommand` object view SHALL expose an `openTarget` action associated with the participants collection.
-The `openTarget` action SHALL have layout sequence `1`.
-The `openTarget` action SHALL open the actual target object when a target participant has an actual target available.
-The `openTarget` action SHALL be disabled when no actual target object is available.
-Target inspection and navigation SHALL be available through target rows in the participants collection.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-- **AND** the participants table appears before the control field set
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in order
-
-#### Scenario: User inspects target through participants
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout does not display separate `targetType` or `targetId` properties
-- **AND** target information is available through the participants table
-
-#### Scenario: User opens actual target from participants action
-- **WHEN** a replayable command target participant has an actual target object available
-- **THEN** the replayable command exposes an `openTarget` action associated with the participants collection
-- **AND** the `openTarget` action has layout sequence `1`
-- **AND** invoking the action opens the actual target object
-
-#### Scenario: User cannot open target without actual target
-- **WHEN** a replayable command has no target participant actual target object available
-- **THEN** the `openTarget` action is disabled
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/tasks.md b/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/tasks.md
deleted file mode 100644
index 5739b6960f9..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-open-target-refinement/tasks.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## 1. Open Target Mixin
-
-- [x] 1.1 Add `ReplayableCommand_openTarget` mixin back to the replay package.
-- [x] 1.2 Configure the mixin action layout with `associateWith = "participants"` and `sequence = "1"`.
-- [x] 1.3 Implement the action to open the actual target object from the target participant.
-- [x] 1.4 Disable the action when no actual target object is available.
-- [x] 1.5 Register the mixin in `CausewayModuleExtCommandLogApplib`.
-
-## 2. Tests and Validation
-
-- [x] 2.1 Add or update tests for opening the actual target object.
-- [x] 2.2 Add or update tests for disabling the action when no actual target is available.
-- [x] 2.3 Run focused command log applib tests for replayable command mapping and participant behaviour.
-- [x] 2.4 Run `openspec validate replayable-command-open-target-refinement --strict`.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/.openspec.yaml b/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/design.md b/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/design.md
deleted file mode 100644
index 7c0505a079c..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/design.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Context
-
-`ReplayableCommand` derives participant rows from the recorded command DTO, replay state, and replay mapping listeners.
-Target and reference parameter rows already have recorded bookmarks before replay.
-The current derivation only exposes actual target and parameter bookmarks after successful replay, even when a replay mapping listener can already provide a mapped bookmark.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Populate actual bookmark values for target participants when replay mapping lookup returns a mapping.
-- Populate actual bookmark values for reference parameter participants when replay mapping lookup returns a mapping.
-- Keep unmapped target and parameter actual bookmarks empty before successful replay.
-- Keep successful replay fallback behaviour for unmapped target and parameter participants.
-- Preserve result participant behaviour.
-
-**Non-Goals:**
-
-- Do not change the replay mapping SPI signatures.
-- Do not change participant layout or column ordering.
-- Do not change replay execution remapping behaviour.
-- Do not add persistence or schema changes.
-
-## Decisions
-
-### Split actual bookmark derivation by role
-
-Target and parameter participants should ask replay mapping listeners first, regardless of replay state.
-If lookup returns a bookmark, that bookmark becomes the actual bookmark shown on the participant.
-If lookup returns no bookmark and the command has replay state `OK`, the participant keeps the current fallback to its recorded bookmark.
-If lookup returns no bookmark and the command is not `OK`, the actual bookmark remains empty.
-
-The alternative was to keep actual values tied entirely to successful replay state, but that hides mappings that are already known before replay.
-
-### Keep result derivation tied to successful replay
-
-Result actual bookmarks should remain tied to successful replay because result mappings are observations produced by replay execution.
-This avoids presenting speculative result actuals before the command has run.
-The alternative was to apply the same eager lookup to results, but that could conflate historical result mappings with the current command execution state.
-
-### Keep listener failure tolerance
-
-Participant derivation should continue to tolerate listener lookup failures and still return rows with recorded bookmarks.
-This keeps the UI usable even when a mapping listener cannot answer a lookup.
-
-## Risks / Trade-offs
-
-- [Risk] Rendering participants may call replay mapping listeners before replay.
- → Mitigate by reusing existing safe lookup handling and keeping failures non-fatal.
-- [Risk] A mapping available before replay might later differ if listener state changes.
- → Mitigate by deriving rows on demand so the table reflects current listener lookup state.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/proposal.md b/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/proposal.md
deleted file mode 100644
index 358d76ec023..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/proposal.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## Why
-
-Replayable command participants currently populate actual target and parameter bookmarks only when the command is already marked successful.
-Users need target and parameter rows to use replay mapping lookup immediately so known mappings are visible before replay as well as after replay.
-
-## What Changes
-
-- Refine participant derivation so target participants ask replay mapping listeners for an actual bookmark whenever a mapping exists.
-- Refine reference parameter participants to ask replay mapping listeners for an actual bookmark whenever a mapping exists.
-- Populate the target or parameter actual bookmark when lookup returns a mapped bookmark.
-- Leave actual bookmark empty for target and parameter participants when lookup returns no mapping and the command has not successfully replayed.
-- Preserve the current successful replay fallback where unchanged target and parameter participants use their recorded bookmark as the actual bookmark.
-- Keep result participant behaviour unchanged.
-- Keep the replay mapping SPI signatures unchanged.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Refines target and parameter participants so available replay mappings populate their actual bookmarks independently of replay success state.
-
-## Impact
-
-- Affects `ReplayableCommand` participant derivation in `extensions/core/commandlog/applib`.
-- Affects focused command log applib tests for participants.
-- No persistence schema, public replay mapping SPI, layout, or result participant changes are expected.
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 489718719b0..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,74 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Replayable command displays command participants
-The system SHALL expose a participants collection on each replayable command.
-The participants collection SHALL contain rows represented by `ReplayableCommandParticipant` view models.
-Each participant SHALL expose the role, parameter name, recorded bookmark, target object, parameter object, result object, and actual bookmark in that order.
-The system SHALL include target participants when the command DTO has recorded target bookmarks.
-The system SHALL include reference parameter participants when the command DTO has recorded reference parameter bookmarks.
-The system MUST NOT include non-reference parameters as bookmark participants.
-The system SHALL include a result participant when the recorded command has a recorded result bookmark.
-Each included participant SHALL expose its recorded bookmark.
-Target participants SHALL expose an actual bookmark whenever replay mapping lookup provides a mapped bookmark.
-Reference parameter participants SHALL expose an actual bookmark whenever replay mapping lookup provides a mapped bookmark.
-Target and reference parameter participants SHALL leave actual bookmarks empty before successful replay when replay mapping lookup provides no mapped bookmark.
-Target and reference parameter participants SHALL use their recorded bookmark as the actual bookmark after successful replay when replay mapping lookup provides no mapped bookmark.
-Result participants SHALL expose actual bookmarks only after the replayable command has successfully replayed.
-When a successful replay has no explicit replacement bookmark for a result participant, the participant SHALL use its recorded bookmark as the actual bookmark.
-
-#### Scenario: Target participant appears in replayable command details
-- **WHEN** a replayable command has recorded target bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `TARGET`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Reference parameter participant appears in replayable command details
-- **WHEN** a replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `PARAMETER`
-- **AND** the participant has parameter name `customer`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Non-reference parameter is omitted
-- **WHEN** a replayable command has parameter `name` recorded as a string value
-- **THEN** the replayable command participants collection does not contain a participant for parameter `name`
-
-#### Scenario: Pending command populates mapped target actual bookmark
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the target participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Pending command populates mapped parameter actual bookmark
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the parameter participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Pending command leaves unmapped target actual bookmark empty
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the target participant has no actual bookmark
-
-#### Scenario: Pending command leaves unmapped parameter actual bookmark empty
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the parameter participant has no actual bookmark
-
-#### Scenario: Successful replay populates mapped target actual bookmark
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the target participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Successful replay keeps unchanged target actual bookmark populated
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the target participant has actual bookmark `demoCustomer:1`
-
-#### Scenario: Successful replay keeps unchanged parameter actual bookmark populated
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the parameter participant has actual bookmark `demoCustomer:1`
diff --git a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/tasks.md b/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/tasks.md
deleted file mode 100644
index 670220e6d10..00000000000
--- a/openspec/changes/archive/2026-06-07-replayable-command-participant-refinements/tasks.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## 1. Participant Actual Bookmark Lookup
-
-- [x] 1.1 Update target participant actual bookmark derivation to use replay mapping lookup before checking replay state.
-- [x] 1.2 Update reference parameter participant actual bookmark derivation to use replay mapping lookup before checking replay state.
-- [x] 1.3 Preserve successful replay fallback to recorded bookmark when no target or parameter mapping exists.
-- [x] 1.4 Preserve result participant actual bookmark behaviour.
-
-## 2. Tests and Validation
-
-- [x] 2.1 Add or update tests for mapped target actual bookmark population before successful replay.
-- [x] 2.2 Add or update tests for mapped parameter actual bookmark population before successful replay.
-- [x] 2.3 Add or update tests for unmapped target and parameter actual bookmarks before and after successful replay.
-- [x] 2.4 Run focused command log applib tests for replayable command mapping and participant behaviour.
-- [x] 2.5 Run `openspec validate replayable-command-participant-refinements --strict`.
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/.openspec.yaml b/openspec/changes/archive/2026-06-07-require-known-action-targets/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/design.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/design.md
deleted file mode 100644
index 3be0a1d87e5..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/design.md
+++ /dev/null
@@ -1,89 +0,0 @@
-## Context
-
-Command-log recording support makes safe actions and synthetic navigate-to actions eligible for command logging so exported command streams can replay user journeys.
-Replay can only execute such streams reliably when every non-service action target can be reached from a previously recorded step.
-Menu service actions provide the roots of the journey because `@DomainService` menu services are globally locatable.
-Synthetic navigate-to actions were introduced so navigation through collections and references can produce command results that establish a path to later targets.
-
-The current command log flow records each eligible command independently.
-A later action can therefore be persisted even if its target was never produced by an earlier logged command and is not a menu service root.
-Blocking such actions during recording is not practical because there is no reliable recording-time boundary that says how far back to search through `CommandLogEntry` history.
-The export manager does have a baseline and selected sequence, so export validation can decide whether the selected sequence is self-contained and replayable.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Define the rules for whether an exported command target is known in an exportable sequence.
-- Validate the selected export sequence before YAML is created.
-- Use the export manager baseline as the lower bound for any prior command/result search.
-- Keep synthetic navigate-to and other safe action result bookmarks as the mechanism for making later targets known.
-- Report the specific command that fails validation.
-
-**Non-Goals:**
-- Block additional commands while recording.
-- Reconstruct paths for existing invalid command log entries.
-- Add a new export YAML field for dotted paths in this change.
-- Change command replay result remapping behavior.
-- Change behavior for applications that record commands but do not attempt to export them.
-
-## Decisions
-
-### Validate in the export action
-
-The export selected action should validate target knowledge after it has resolved and sorted the selected command log entries, and before it creates the YAML `Clob`.
-If validation fails, the action should be disabled or rejected with a clear validation message that identifies the failing command and target.
-
-Alternative considered: validate at command recording completion.
-That would reject invalid actions earlier, but it requires guessing how far back in command history to search and could incorrectly block legitimate recordings.
-
-### Use the export baseline as the search boundary
-
-The validator should use the export manager baseline to define the start of the exportable range.
-A target can be known from commands selected for export and from prior commands at or after the baseline when those prior commands are part of the same exportable history.
-Commands before the baseline should not be considered because they are outside the export manager's current recording/export window.
-
-Alternative considered: search all historical command log entries for a matching result bookmark.
-That would make many targets appear known without proving they are reachable within the export being produced.
-
-### Model known targets from roots and results
-
-The validator should treat an action target as known when one of these conditions holds:
-- the target is a menu service annotated as a domain service, because menu services are export roots;
-- the target bookmark matches the result bookmark of an earlier command in the baseline-bounded exportable sequence;
-- the target belongs to a command outside the selected export action set and is therefore not being exported in this operation.
-
-Alternative considered: treat any resolvable bookmark as known.
-That would make local object lookup sufficient, but it would not provide a replay path and would defeat the purpose of recording navigation steps.
-
-### Use result metadata as the path edge
-
-No new persistent dotted-path field is required for this change.
-The sequence order, export baseline, selected commands, and existing result bookmark metadata provide the graph edges needed by export and replay tooling.
-Synthetic navigate-to actions should continue to be ordinary logged safe actions whose result establishes the target for later commands.
-
-Alternative considered: persist an explicit path string on each command log entry.
-That would make validation independent of sequence scanning, but it would add a data model concern before the current replay/export contract needs it.
-
-## Risks / Trade-offs
-
-- [Risk] Users can still record commands that cannot be exported on their own.
- → Mitigate by preventing export and explaining which command needs an earlier navigation or finder result.
-- [Risk] Determining whether a service target is a root may differ between service objects and command DTO bookmark shape.
- → Mitigate by using the metamodel or specification loader to recognize domain service action targets rather than relying only on bookmark strings.
-- [Risk] Baseline-bounded sequence scanning could be expensive for large export ranges.
- → Mitigate by validating only when export is requested and by scanning in export order once.
-- [Risk] Nested commands or sibling command ordering may affect what counts as earlier.
- → Mitigate by using existing command log timestamp and interaction ordering consistently with export ordering.
-
-## Migration Plan
-
-No schema migration is expected.
-Existing command log entries remain unchanged.
-After deployment, applications may continue recording commands as before.
-Export will refuse selected command sequences that are not replayable from the export manager baseline.
-If needed, rollback by reverting the export validation change.
-
-## Open Questions
-
-- Should validation be implemented only as `validateSelected(...)`, or should `act(...)` also guard against callers that bypass UI validation?
-- What command identity should appear in the validation message: interaction id, timestamp, logical member identifier, or all of them?
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/proposal.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/proposal.md
deleted file mode 100644
index b17b821fac3..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/proposal.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## Why
-
-Recorded command export must be replayable as a navigable sequence, which requires every action target to have a known dotted path from a root menu service or a previously recorded result.
-During normal recording, however, it is difficult to know how far back to search in `CommandLogEntry` history to decide whether a target is known.
-The export manager already has a baseline and selected command sequence, so export is the right point to validate whether the sequence is actually exportable.
-
-## What Changes
-
-- Validate the export manager's selected command sequence before creating YAML.
-- Use the export manager baseline to define how far back target-knownness searches may go.
-- Treat menu service actions on `@DomainService` objects as root actions that are always valid starting points for an exported sequence.
-- Treat targets returned by earlier commands in the exportable range, including synthetic navigate-to actions, as known targets that can be used by later exported actions.
-- Prevent export when any selected action uses an unknown target.
-- Report a validation message that identifies which command failed and why the target is not exportable.
-- Do not block additional commands while recording.
-
-## Capabilities
-
-### New Capabilities
-- `command-export-known-targets`: Defines target knowledge and validation rules for exportable command sequences.
-
-### Modified Capabilities
-- `safe-action-command-publishing`: Clarifies that synthetic selector and navigate-to safe action results can establish known targets for later exported actions.
-- `command-export-yaml-result`: Clarifies that command export validates selected sequences using prior result metadata before emitting YAML.
-
-## Impact
-
-- Command export manager validation and export action behavior.
-- Command export and replay semantics for action target resolution.
-- Synthetic navigate-to action handling and safe action command publishing.
-- Applications using recording support may continue recording arbitrary commands, but invalid sequences will be prevented from exporting until the missing navigation or finder command is included.
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-known-targets/spec.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-known-targets/spec.md
deleted file mode 100644
index be61e40611f..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-known-targets/spec.md
+++ /dev/null
@@ -1,80 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Export validates known action targets
-The export manager SHALL validate the target of every selected action command before creating export YAML.
-The export manager SHALL treat an action target as known only when the target is an export root or when the target bookmark was produced as the result of an earlier command in the baseline-bounded exportable sequence.
-If a selected action target is unknown, the export manager MUST prevent the export from occurring.
-The validation message SHALL identify the failing command and SHALL state that the target is unknown for command export.
-The validation message SHALL indicate that a navigation or finder action returning the target must be included earlier in the exportable sequence.
-The system MUST NOT block additional commands while recording merely because their targets are not yet known.
-
-#### Scenario: Root service action is accepted for export
-- **GIVEN** an export manager has a selected action command whose target is a menu service annotated with `@DomainService`
-- **WHEN** the export manager validates the selected command sequence
-- **THEN** the system accepts the command as a root action for the export sequence
-
-#### Scenario: Action on previously returned target is accepted for export
-- **GIVEN** an export manager baseline is set
-- **AND** an earlier command at or after the baseline has result bookmark `demoCustomer:1`
-- **AND** a selected later action command targets bookmark `demoCustomer:1`
-- **WHEN** the export manager validates the selected command sequence
-- **THEN** the system accepts the later command for export
-
-#### Scenario: Action on unknown target is rejected for export
-- **GIVEN** an export manager baseline is set
-- **AND** a selected action command targets bookmark `demoCustomer:1`
-- **AND** the target bookmark `demoCustomer:1` is not a menu service root
-- **AND** no earlier command at or after the baseline has result bookmark `demoCustomer:1`
-- **WHEN** the export manager validates the selected command sequence
-- **THEN** the system prevents the export from occurring
-- **AND** the validation message identifies the selected command that targets `demoCustomer:1`
-
-#### Scenario: Recording is not blocked by unknown target
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** no earlier command has result bookmark `demoCustomer:1`
-- **WHEN** a user invokes an action command that targets bookmark `demoCustomer:1`
-- **THEN** the system does not reject the action merely because command export might later find the target unknown
-
-### Requirement: Export roots are menu domain services
-The export manager SHALL treat actions invoked on menu services annotated with `@DomainService` as root actions for command export.
-Root actions SHALL be valid even when no earlier command result references the service target.
-Root action results SHALL establish known target bookmarks for later selected commands when the command log entry stores a non-null result bookmark.
-The export manager MUST NOT treat ordinary persisted domain objects as roots merely because their bookmarks can be resolved locally.
-
-#### Scenario: Service finder establishes a known export target
-- **GIVEN** an export manager baseline is set
-- **AND** a menu service finder action at or after the baseline returns bookmark `demoCustomer:1`
-- **WHEN** a selected later command targets bookmark `demoCustomer:1`
-- **THEN** bookmark `demoCustomer:1` is known for command export
-
-#### Scenario: Locally resolvable object is not an export root
-- **GIVEN** an export manager baseline is set
-- **AND** bookmark `demoCustomer:1` resolves to a local domain object
-- **AND** no earlier command at or after the baseline produced `demoCustomer:1`
-- **WHEN** a selected action command targets bookmark `demoCustomer:1`
-- **THEN** the export manager rejects the selected sequence because local resolvability does not make the target an export root
-
-### Requirement: Export target knowledge follows baseline-bounded export order
-The export manager SHALL evaluate target knowledge using the same command ordering that command export uses for replayable sequences.
-A command result SHALL make a bookmark known only for selected commands that occur later in that ordering.
-A command result MUST NOT make the same bookmark known for an earlier selected command or for another selected command whose ordering is not after the result-producing command.
-A command before the export manager baseline MUST NOT make a target known for the selected export sequence.
-
-#### Scenario: Later result does not validate earlier selected target
-- **GIVEN** an export manager baseline is set
-- **AND** a selected action command targets bookmark `demoCustomer:1`
-- **AND** a later selected command in export order has result bookmark `demoCustomer:1`
-- **WHEN** the export manager validates the selected command sequence
-- **THEN** the system rejects the earlier selected command because the target was not known at that point in the export sequence
-
-#### Scenario: Earlier result validates later selected target
-- **GIVEN** an export manager baseline is set
-- **AND** a command with result bookmark `demoCustomer:1` appears earlier in export order and at or after the baseline
-- **WHEN** a selected later action command targets bookmark `demoCustomer:1`
-- **THEN** the export manager accepts the later command for export
-
-#### Scenario: Result before baseline does not validate selected target
-- **GIVEN** an export manager baseline is set
-- **AND** a command before the baseline has result bookmark `demoCustomer:1`
-- **WHEN** a selected later action command targets bookmark `demoCustomer:1`
-- **THEN** the export manager rejects the selected command unless another command at or after the baseline establishes `demoCustomer:1`
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 1b377532f74..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Exported command sequences contain only reachable action targets
-The system SHALL validate selected command export sequences before emitting YAML.
-The system SHALL rely on recorded result metadata at or after the export manager baseline to prove that later exported action targets are reachable from earlier commands in the same exportable range.
-An exported action command whose target is not a menu service root SHALL have a target bookmark that was recorded as the result of an earlier command in the baseline-bounded exportable range.
-Command export MUST NOT silently compensate for an unknown action target by fabricating result metadata or by inventing a path that was not recorded.
-If selected command log data contains an action with an unknown target, export SHALL reject the sequence with a clear validation message rather than emitting unreplayable YAML.
-The validation message SHALL identify the command that failed validation.
-
-#### Scenario: Export sequence uses earlier result as later target
-- **GIVEN** an export manager baseline is set
-- **AND** an exportable command at or after the baseline has result bookmark `demoCustomer:1`
-- **AND** a later selected action command targets bookmark `demoCustomer:1`
-- **WHEN** the commands are exported
-- **THEN** the exported YAML preserves both commands in replay order
-- **AND** the earlier command includes result metadata that makes the later target reachable
-
-#### Scenario: Export rejects unknown target in selected data
-- **GIVEN** an export manager baseline is set
-- **AND** a selected action command targets bookmark `demoCustomer:1`
-- **AND** the target is not a menu service root
-- **AND** no earlier command at or after the baseline has result bookmark `demoCustomer:1`
-- **WHEN** the commands are exported
-- **THEN** the system rejects the export sequence as unreplayable
-- **AND** the validation message identifies the selected command that failed
-- **AND** the system does not emit YAML for that invalid sequence
-
-#### Scenario: Export does not fabricate target path metadata
-- **GIVEN** an export manager baseline is set
-- **AND** a selected action command targets bookmark `demoCustomer:1`
-- **AND** no earlier command at or after the baseline has result bookmark `demoCustomer:1`
-- **WHEN** the commands are exported
-- **THEN** the system does not add synthetic result metadata solely to make the sequence appear reachable
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/safe-action-command-publishing/spec.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/safe-action-command-publishing/spec.md
deleted file mode 100644
index 483c530e063..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/specs/safe-action-command-publishing/spec.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Logged navigation actions establish known export targets
-When command-log recording support is `ENABLED`, logged safe actions that return bookmarkable domain objects SHALL make those result bookmarks available as known targets for later command export validation.
-Synthetic parented collection navigate-to actions SHALL make their returned child bookmark available as a known export target when their command log entry stores that bookmark as the result.
-Synthetic scalar reference navigate-to actions SHALL make their returned referenced-object bookmark available as a known export target when their command log entry stores that bookmark as the result.
-Safe actions that do not store a result bookmark MUST NOT establish a known target for later exported actions.
-
-#### Scenario: Finder safe action establishes a later export target
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** a logged safe finder action returns bookmark `demoCustomer:1`
-- **WHEN** a later selected export action targets bookmark `demoCustomer:1`
-- **THEN** the later target is known from the safe action result if the safe action is within the export manager baseline
-
-#### Scenario: Parented collection navigate-to action establishes a child export target
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** a synthetic parented collection navigate-to command returns bookmark `demoLine:1`
-- **WHEN** a later selected export action targets bookmark `demoLine:1`
-- **THEN** the later target is known from the synthetic navigate-to result if the navigate-to command is within the export manager baseline
-
-#### Scenario: Scalar reference navigate-to action establishes a referenced export target
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** a synthetic scalar reference navigate-to command returns bookmark `demoLease:1`
-- **WHEN** a later selected export action targets bookmark `demoLease:1`
-- **THEN** the later target is known from the synthetic navigate-to result if the navigate-to command is within the export manager baseline
-
-#### Scenario: Safe action without result does not establish a later export target
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** a logged safe action has no result bookmark
-- **WHEN** a later selected export action targets bookmark `demoCustomer:1`
-- **THEN** the safe action without a result does not make bookmark `demoCustomer:1` known
diff --git a/openspec/changes/archive/2026-06-07-require-known-action-targets/tasks.md b/openspec/changes/archive/2026-06-07-require-known-action-targets/tasks.md
deleted file mode 100644
index d96fe65705e..00000000000
--- a/openspec/changes/archive/2026-06-07-require-known-action-targets/tasks.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## 1. Locate Export Integration Points
-
-- [x] 1.1 Identify how `CommandExportManager` stores and exposes its baseline timestamp or state.
-- [x] 1.2 Identify where `CommandExportManager_exportSelected` resolves, sorts, validates, and exports selected `CommandLogEntry` records.
-- [x] 1.3 Identify the command DTO target bookmark extraction API used by replay/export for action targets.
-- [x] 1.4 Identify the metamodel or service registry API that reliably classifies `@DomainService` menu service action targets as export roots.
-
-## 2. Implement Export Known Target Validation
-
-- [x] 2.1 Add a focused known-target validator in the command-log applib export/replay layer.
-- [x] 2.2 Make the validator operate on the export manager baseline and selected export sequence, not on command recording completion.
-- [x] 2.3 Accept action commands whose targets are menu domain service roots.
-- [x] 2.4 Accept action commands whose target bookmark appears as the result bookmark of an earlier command at or after the export manager baseline.
-- [x] 2.5 Reject unknown non-root targets during export validation without blocking recording of future commands.
-- [x] 2.6 Ensure the validation message identifies the failing command and unknown target bookmark.
-
-## 3. Integrate Navigation Results
-
-- [x] 3.1 Ensure logged safe action result bookmarks within the baseline-bounded export range are visible to the known-target validator as known targets for later selected commands.
-- [x] 3.2 Ensure synthetic parented collection navigate-to command results establish known child targets for later selected commands.
-- [x] 3.3 Ensure synthetic scalar reference navigate-to command results establish known referenced-object targets for later selected commands.
-- [x] 3.4 Ensure safe actions without result bookmarks do not establish unrelated known targets.
-
-## 4. Guard Export of Invalid Sequences
-
-- [x] 4.1 Wire export-time validation into `CommandExportManager_exportSelected.validateSelected(...)` so invalid selections are disabled before invocation.
-- [x] 4.2 Also guard `CommandExportManager_exportSelected.act(...)` so callers that bypass UI validation cannot emit invalid YAML.
-- [x] 4.3 Ensure export validation uses the same ordering semantics as command export and does not fabricate path metadata.
-- [x] 4.4 Surface an export validation error that identifies the unknown target bookmark and the affected command.
-
-## 5. Tests and Documentation
-
-- [x] 5.1 Add unit tests for root menu service targets, previously returned targets, unknown targets, baseline exclusion, and locally resolvable but unreached targets.
-- [x] 5.2 Add tests proving safe finder actions and synthetic navigate-to actions establish known targets through result bookmarks within the export manager baseline.
-- [x] 5.3 Add export action tests for valid reachable selections and invalid selected command log data.
-- [x] 5.4 Add a test proving recording is not blocked by known-target validation.
-- [x] 5.5 Run targeted commandlog applib tests and any affected metamodel tests.
-- [x] 5.6 Run `openspec status --change require-known-action-targets` and address any artifact validation issues.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-command-result/.openspec.yaml b/openspec/changes/archive/2026-06-07-show-replayable-command-result/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-command-result/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-command-result/design.md b/openspec/changes/archive/2026-06-07-show-replayable-command-result/design.md
deleted file mode 100644
index a321bca74f4..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-command-result/design.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Context
-
-ReplayableCommand is a view model over command-log entries used to inspect and replay imported commands.
-It currently renders the recorded `CommandDto` as YAML through the `dto` property and exposes replay state, target, member, and timestamp details.
-Command export and import already preserve returned object metadata as a `result` element containing bookmark `type` and `id` values.
-That metadata is stored on the associated `CommandLogEntry`, but it is not visible directly on ReplayableCommand.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Expose recorded result bookmark metadata on ReplayableCommand using the same shape users see in exported YAML.
-- Keep the new display read-only and inspection-oriented.
-- Preserve the existing command DTO display and replay behavior.
-- Cover result-present and result-absent cases with focused tests.
-
-**Non-Goals:**
-
-- Change the command export YAML format.
-- Change command replay execution or replay mapping listener behavior.
-- Resolve the recorded result bookmark to a live domain object as part of the display.
-- Reintroduce or display the legacy `returnedObject` field name.
-
-## Decisions
-
-- Render the existing ReplayableCommand DTO property as a `CommandExportDto` YAML wrapper.
- This keeps command and result metadata together in the same shape used by exported command YAML.
- An alternative was to add a separate result property, but that would split the export wrapper across two UI properties and make inspection less faithful to the exported form.
-
-- Populate the `CommandExportDto` result metadata from `CommandLogEntry#getResult()` using `type` and `id` fields.
- This matches the export wrapper contract while avoiding object resolution.
- An alternative was to display a `Bookmark` string, but that would not match the exported `result` element shape requested by users.
-
-- Omit or render no value when a command has no recorded result bookmark.
- This mirrors exported YAML, where result metadata is absent for commands without a result.
- An alternative was to show an explicit empty YAML block, but that would make absent data look present.
-
-## Risks / Trade-offs
-
-- [Risk] The result is stored on `CommandLogEntry`, while ReplayableCommand caches only selected command data.
- → Mitigation: Read the result through the existing command-log-entry lookup path and invalidate behavior only if necessary.
-
-- [Risk] A result bookmark might not resolve in the current environment after import.
- → Mitigation: Display bookmark metadata only and do not require object lookup.
-
-- [Risk] Table views could become noisy if result metadata is shown in collection tables.
- → Mitigation: Use layout settings consistent with the existing DTO property and hide the detailed result from tables if the implementation chooses an AsciiDoc/YAML rendering.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-command-result/proposal.md b/openspec/changes/archive/2026-06-07-show-replayable-command-result/proposal.md
deleted file mode 100644
index 838a75a0900..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-command-result/proposal.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## Why
-
-ReplayableCommand currently exposes the recorded `CommandDto` but hides the result metadata stored alongside imported/exported commands.
-Operators need to inspect replay inputs and the recorded returned object in one place so they can verify replay mappings and exported command streams without opening the underlying command log entry.
-
-## What Changes
-
-- Add the recorded result metadata to the ReplayableCommand view model when a result bookmark is available.
-- Render the result using the same logical type and identifier shape used by exported command YAML under the `result` element.
-- Leave commands without result metadata unchanged.
-- Preserve the existing command DTO display and replay behavior.
-
-## Capabilities
-
-### New Capabilities
-
-### Modified Capabilities
-- `command-export-yaml-result`: ReplayableCommand exposes the exported `result` metadata for inspection.
-
-## Impact
-
-- Affects the command-log applib replay view model, especially `ReplayableCommand` and related tests.
-- May add a read-only property or DTO field rendering for the recorded result bookmark.
-- No expected changes to replay execution, import/export YAML format, or public replay mapping SPI contracts.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-command-result/specs/command-export-yaml-result/spec.md b/openspec/changes/archive/2026-06-07-show-replayable-command-result/specs/command-export-yaml-result/spec.md
deleted file mode 100644
index 3eda608875f..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-command-result/specs/command-export-yaml-result/spec.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replayable command displays exported result metadata
-The system SHALL expose recorded result metadata on ReplayableCommand when the underlying command log entry has a non-null result bookmark.
-The displayed result metadata SHALL use the same `result` element shape as exported command YAML, with `type` and `id` fields derived from the result bookmark.
-The system SHALL leave ReplayableCommand result metadata absent when the underlying command log entry has no result bookmark.
-The system MUST NOT display the legacy `returnedObject` field name for ReplayableCommand result metadata.
-The system MUST NOT require the result bookmark to resolve to a live domain object before displaying the metadata.
-
-#### Scenario: Replayable command with recorded result
-- **WHEN** a ReplayableCommand wraps a command log entry whose result bookmark is `demoCustomer:1`
-- **THEN** ReplayableCommand displays result metadata using field `result` with type `demoCustomer` and id `1`
-- **AND** ReplayableCommand does not display field `returnedObject`
-
-#### Scenario: Replayable command without recorded result
-- **WHEN** a ReplayableCommand wraps a command log entry whose result bookmark is null
-- **THEN** ReplayableCommand does not display result metadata
-- **AND** ReplayableCommand does not display field `returnedObject`
-
-#### Scenario: Replayable command result is unresolved locally
-- **WHEN** a ReplayableCommand wraps an imported command log entry whose result bookmark does not resolve to a local domain object
-- **THEN** ReplayableCommand still displays the bookmark type and id as result metadata
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-command-result/tasks.md b/openspec/changes/archive/2026-06-07-show-replayable-command-result/tasks.md
deleted file mode 100644
index ba2713d07f5..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-command-result/tasks.md
+++ /dev/null
@@ -1,13 +0,0 @@
-## 1. ReplayableCommand Result Display
-
-- [x] 1.1 Inspect current ReplayableCommand properties and layout to choose where the recorded result display belongs.
-- [x] 1.2 Update the read-only ReplayableCommand DTO property to render a `CommandExportDto` containing command data and exported `result` metadata with `type` and `id` fields.
-- [x] 1.3 Ensure the property is absent or empty when no result bookmark is recorded and never emits `returnedObject`.
-- [x] 1.4 Ensure the property displays bookmark metadata without resolving the bookmark to a domain object.
-
-## 2. Tests and Validation
-
-- [x] 2.1 Add focused tests for ReplayableCommand result display with a recorded result bookmark.
-- [x] 2.2 Add focused tests for no recorded result and unresolved-result behavior.
-- [x] 2.3 Run the relevant command-log applib tests.
-- [x] 2.4 Run `openspec validate show-replayable-command-result --strict`.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/.openspec.yaml b/openspec/changes/archive/2026-06-07-show-replayable-remappings/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/design.md b/openspec/changes/archive/2026-06-07-show-replayable-remappings/design.md
deleted file mode 100644
index c004a30ddb4..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/design.md
+++ /dev/null
@@ -1,66 +0,0 @@
-## Context
-
-`ReplayableCommand` is a view model around a `CommandLogEntry` and already parses the recorded command DTO to display command metadata and YAML.
-Replay execution remaps command targets and reference action parameters by asking the configured `CommandReplayMappingListener` instances for an actual bookmark before executing a copied DTO.
-Successful replay also records result mappings by notifying listeners with the recorded result bookmark and the actual replay result bookmark.
-The UI currently requires users to infer those remappings from raw DTO YAML or separate replay result mapping screens.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Add a `ReplayableCommandParticipant` view model for remapping rows derived from a replayable command.
-- Add a collection on `ReplayableCommand` that lists recorded target, reference parameter, and result participants, with actual bookmarks populated after successful replay.
-- Include target, reference parameter, and result participants in the same table.
-- Resolve target and parameter actual bookmarks to objects when possible.
-- Resolve result actual bookmarks only after the replayable command is in a successful replay state.
-- Provide fallback layout metadata for the new view model and include the collection in `ReplayableCommand.layout.fallback.xml`.
-
-**Non-Goals:**
-- Do not change the replay mapping SPI signatures.
-- Do not add persistence or schema changes.
-- Do not mutate the recorded command DTO while preparing UI rows.
-- Do not expose non-reference action parameters as remapping participants.
-
-## Decisions
-
-### Derive rows on demand from the replayable command
-
-The remappings collection will be calculated by parsing the command DTO owned by the current `ReplayableCommand` instead of storing a second representation.
-This keeps the view model consistent with the recorded command and avoids migration concerns.
-The alternative was to persist participant rows when replay runs, but that would duplicate command DTO state and require schema changes.
-
-### Use a dedicated participant view model
-
-Each row will be a `ReplayableCommandParticipant` view model with properties for owning interaction id, role, target, parameter name, result, recorded bookmark, and actual bookmark.
-This provides layout metadata and table column control independent of `ReplayableCommand`.
-The alternative was to use a DTO-like inner class, but that would make fallback layout and future object actions harder to control.
-
-### Use replay mapping lookup for target and parameter participants
-
-Target and reference parameter rows will start from recorded bookmarks in the command DTO and ask the configured replay mapping listeners for actual bookmarks using the same lookup contract used by replay execution.
-Rows without an actual replacement will still be included so that recorded participants are visible before replay.
-After successful replay, rows without an explicit actual replacement will use the recorded bookmark as their actual bookmark.
-Listener failures will not break the UI and will be handled consistently with replay-time lookup behaviour.
-
-### Show result participant before replay and actual result after success
-
-The result row will be included when the recorded result bookmark is available.
-Before replay succeeds, only the recorded result bookmark is shown.
-After replay succeeds, the actual result bookmark is found from replay mapping data, or falls back to the recorded result bookmark when no explicit mapping exists.
-If the actual result cannot be resolved to an object, the bookmark fields still show the recorded and actual values.
-
-### Resolve objects best-effort
-
-The participant view model will keep bookmark values as the source of truth and use `BookmarkService` to resolve target, parameter, and result objects only when allowed by role and replay state.
-This preserves usability for unresolved or external bookmarks and avoids making object resolution a precondition for displaying remappings.
-
-## Risks / Trade-offs
-
-- [Risk] Recomputing the collection can invoke replay mapping listeners during page rendering.
- → Mitigate by using safe, best-effort lookup and keeping the collection limited to the current command DTO participants.
-- [Risk] Multiple mapping listeners could provide conflicting replacements.
- → Mitigate by following replay-time precedence or first-available behaviour so the table reflects execution behaviour.
-- [Risk] Parameter names may be unavailable in older or unusual command DTOs.
- → Mitigate by leaving `parameterName` blank while still displaying role and bookmark values.
-- [Risk] Result mapping lookup depends on available mapping data.
- → Mitigate by omitting the result row unless the command is successfully replayed and an actual bookmark can be found.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/proposal.md b/openspec/changes/archive/2026-06-07-show-replayable-remappings/proposal.md
deleted file mode 100644
index 24d30be64a5..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/proposal.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## Why
-
-Replayable command details currently show the recorded command DTO, but they do not make replay-time bookmark remappings visible at the point where the user reviews or replays the command.
-Users need to see which target, reference parameter, or result bookmarks differed between the recorded command and the actual replay so that replay behaviour is auditable without manually comparing DTOs or separate mapping lists.
-
-## What Changes
-
-- Add a replayable command participants collection named `Participants` that is populated on the fly from the command DTO, replay state, and replay mapping listeners or persisted mapping data.
-- Represent each remapping row with a new `ReplayableCommandParticipant` view model.
-- Display participant role, parameter name, recorded bookmark, target object, parameter object, result object, and actual bookmark.
-- Resolve target and parameter bookmarks to local domain objects when possible, while still showing bookmark values when objects cannot be resolved.
-- Resolve actual bookmarks and objects only when the command has replayed successfully.
-- Add fallback layout metadata for `ReplayableCommandParticipant`.
-- Update the fallback layout metadata for `ReplayableCommand` to include the participants table.
-
-## Capabilities
-
-### New Capabilities
-- `replayable-command-remappings`: Displays replay-time target, reference parameter, and result bookmark remappings from a replayable command.
-
-### Modified Capabilities
-- `command-replay-result-mapping`: Replayable command inspection surfaces the remappings that replay mapping SPI lookup and result notifications make relevant to a command.
-
-## Impact
-
-- Affects the command log applib replay UI under `extensions/core/commandlog/applib`.
-- Adds a new view model and layout metadata alongside `ReplayableCommand`.
-- Updates `ReplayableCommand.layout.fallback.xml` to expose the collection.
-- Adds or updates unit tests for parsing command DTO participants, looking up actual bookmarks, and rendering remapping rows.
-- No persistence schema or public replay mapping SPI changes are expected.
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/command-replay-result-mapping/spec.md b/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/command-replay-result-mapping/spec.md
deleted file mode 100644
index 01d0d57bc78..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/command-replay-result-mapping/spec.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replayable command inspection surfaces relevant replay mappings
-The system SHALL make replay mapping data relevant to a replayable command visible from that replayable command's UI.
-The visible data SHALL include target bookmark replacements discovered through replay mapping lookup.
-The visible data SHALL include reference parameter bookmark replacements discovered through replay mapping lookup.
-The visible data SHALL include recorded target, reference parameter, and result bookmarks before replay.
-The visible data SHALL include actual target, reference parameter, and result bookmarks after the replayable command has successfully replayed.
-The system SHALL preserve the existing replay mapping SPI contracts while surfacing this data.
-
-#### Scenario: User inspects replay input participants
-- **WHEN** a replayable command has a recorded target or reference parameter bookmark
-- **THEN** the replayable command UI exposes the recorded bookmark for that participant
-
-#### Scenario: User inspects replay input remappings after success
-- **WHEN** a replayable command target or reference parameter is remapped by the replay mapping lookup flow
-- **AND** the replayable command has successfully replayed
-- **THEN** the replayable command UI exposes the recorded bookmark and actual bookmark for that participant
-
-#### Scenario: User inspects replay result remapping after success
-- **WHEN** a replayable command has replayed successfully
-- **AND** the command has a recorded result bookmark mapped to an actual result bookmark
-- **THEN** the replayable command UI exposes the recorded result bookmark and actual result bookmark
-
-#### Scenario: Replay mapping SPI remains source-compatible
-- **WHEN** an application implements `CommandReplayMappingListener`
-- **THEN** the implementation remains source-compatible with the replay mapping SPI
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 64ad8ac07e1..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,103 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replayable command displays command participants
-The system SHALL expose a participants collection on each replayable command.
-The participants collection SHALL contain rows represented by `ReplayableCommandParticipant` view models.
-Each participant SHALL expose the role, parameter name, recorded bookmark, target object, parameter object, result object, and actual bookmark in that order.
-The system SHALL include target participants when the command DTO has recorded target bookmarks.
-The system SHALL include reference parameter participants when the command DTO has recorded reference parameter bookmarks.
-The system MUST NOT include non-reference parameters as bookmark participants.
-The system SHALL include a result participant when the recorded command has a recorded result bookmark.
-Each included participant SHALL expose its recorded bookmark.
-Participants SHALL expose actual bookmarks only after the replayable command has successfully replayed.
-When a successful replay has no explicit replacement bookmark for a target, parameter, or result participant, the participant SHALL use its recorded bookmark as the actual bookmark.
-
-#### Scenario: Target participant appears in replayable command details
-- **WHEN** a replayable command has recorded target bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `TARGET`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Reference parameter participant appears in replayable command details
-- **WHEN** a replayable command has reference parameter `customer` recorded as bookmark `demoCustomer:1`
-- **THEN** the replayable command participants collection contains a participant with role `PARAMETER`
-- **AND** the participant has parameter name `customer`
-- **AND** the participant has recorded bookmark `demoCustomer:1`
-
-#### Scenario: Non-reference parameter is omitted
-- **WHEN** a replayable command has parameter `name` recorded as a string value
-- **THEN** the replayable command participants collection does not contain a participant for parameter `name`
-
-#### Scenario: Successful replay populates actual target bookmark
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides actual bookmark `demoCustomer:2`
-- **THEN** the target participant has actual bookmark `demoCustomer:2`
-
-#### Scenario: Successful replay keeps unchanged target actual bookmark populated
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the replayable command has recorded target bookmark `demoCustomer:1`
-- **AND** replay mapping lookup provides no actual bookmark
-- **THEN** the target participant has actual bookmark `demoCustomer:1`
-
-### Requirement: Replayable command participant resolves target, parameter, and result objects best-effort
-The `ReplayableCommandParticipant` view model SHALL expose a target object for target participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL expose a parameter object for parameter participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL expose a result object for result participants when the actual bookmark resolves locally.
-The `ReplayableCommandParticipant` view model SHALL still expose recorded and actual bookmark values when the actual bookmark cannot be resolved locally.
-The system MUST NOT require recorded bookmarks to resolve locally in order to display a participant.
-
-#### Scenario: Target participant resolves actual object
-- **WHEN** a target participant has actual bookmark `demoCustomer:2`
-- **AND** bookmark lookup resolves `demoCustomer:2` to a local domain object
-- **THEN** the participant target property exposes that local domain object
-- **AND** the participant still displays recorded bookmark `demoCustomer:1`
-- **AND** the participant still displays actual bookmark `demoCustomer:2`
-
-#### Scenario: Parameter participant resolves actual object
-- **WHEN** a parameter participant has actual bookmark `demoCustomer:2`
-- **AND** bookmark lookup resolves `demoCustomer:2` to a local domain object
-- **THEN** the participant parameter property exposes that local domain object
-- **AND** the participant still displays recorded bookmark `demoCustomer:1`
-- **AND** the participant still displays actual bookmark `demoCustomer:2`
-
-#### Scenario: Parameter participant keeps unresolved bookmark values
-- **WHEN** a reference parameter participant has actual bookmark `external.Customer:2`
-- **AND** bookmark lookup cannot resolve `external.Customer:2` to a local domain object
-- **THEN** the participant parameter property is empty
-- **AND** the participant still displays recorded bookmark `external.Customer:1`
-- **AND** the participant still displays actual bookmark `external.Customer:2`
-
-### Requirement: Replayable command participant displays result after replay
-The system SHALL include a result participant whenever the replayable command has a recorded result bookmark.
-The result participant SHALL use the command's recorded result bookmark.
-The result participant SHALL expose the actual result bookmark after the replayable command has successfully replayed.
-The `ReplayableCommandParticipant` view model SHALL expose a result object for result participants when the actual result bookmark resolves locally.
-The system MUST NOT resolve or display a result object for commands that have not successfully replayed.
-
-#### Scenario: Pending command displays recorded result participant only
-- **WHEN** a replayable command has replay state `PENDING`
-- **AND** the command has recorded result bookmark `demoInvoice:1`
-- **THEN** the replayable command participants collection contains a participant with role `RESULT`
-- **AND** the participant has recorded bookmark `demoInvoice:1`
-- **AND** the participant has no actual bookmark
-
-#### Scenario: Successful replay displays result actual bookmark
-- **WHEN** a replayable command has replay state `OK`
-- **AND** the command has recorded result bookmark `demoInvoice:1`
-- **AND** replay mapping data provides actual result bookmark `demoInvoice:2`
-- **THEN** the replayable command participants collection contains a participant with role `RESULT`
-- **AND** the participant has recorded bookmark `demoInvoice:1`
-- **AND** the participant has actual bookmark `demoInvoice:2`
-
-### Requirement: Replayable participant layouts expose participant data
-The system SHALL provide fallback layout metadata for `ReplayableCommandParticipant`.
-The participant layout SHALL expose role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in that order.
-The `ReplayableCommand` fallback layout SHALL include the participants collection as a table named `Participants`.
-
-#### Scenario: User views participants table on a replayable command
-- **WHEN** a user views a replayable command using fallback layout metadata
-- **THEN** the layout includes the participants collection as a table named `Participants`
-
-#### Scenario: User views participant fields
-- **WHEN** a user views a replayable command participant using fallback layout metadata
-- **THEN** the layout displays the participant role, parameter name, recorded bookmark, target, parameter, result, and actual bookmark in order
diff --git a/openspec/changes/archive/2026-06-07-show-replayable-remappings/tasks.md b/openspec/changes/archive/2026-06-07-show-replayable-remappings/tasks.md
deleted file mode 100644
index 49c26d0b096..00000000000
--- a/openspec/changes/archive/2026-06-07-show-replayable-remappings/tasks.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## 1. Participant Model
-
-- [x] 1.1 Add `ReplayableCommandParticipant` view model in the replay package with role, owning interaction id, parameter name, recorded bookmark, and actual bookmark properties.
-- [x] 1.2 Add best-effort target and result object properties that use `BookmarkService` and keep bookmark values visible when lookup fails.
-- [x] 1.3 Add role handling for `TARGET`, `PARAMETER`, and `RESULT` participants.
-
-## 2. Replayable Command Collection
-
-- [x] 2.1 Add a participants collection to `ReplayableCommand` that parses command targets from the recorded command DTO.
-- [x] 2.2 Add reference parameter parsing that captures parameter names and ignores non-reference parameters.
-- [x] 2.3 Use replay mapping listener lookup to find actual bookmarks for target and reference parameter participants.
-- [x] 2.4 Add result participant derivation only for successfully replayed commands with recorded and actual result mapping data.
-- [x] 2.5 Ensure participant derivation does not mutate the recorded command DTO and tolerates listener lookup failures.
-
-## 3. Layout Metadata
-
-- [x] 3.1 Add `ReplayableCommandParticipant.layout.fallback.xml` with participant fields and bookmark values.
-- [x] 3.2 Add `ReplayableCommandParticipant.columnOrder.fallback.txt` if needed for table column order.
-- [x] 3.3 Update `ReplayableCommand.layout.fallback.xml` to show the participants collection as a table.
-
-## 4. Tests and Validation
-
-- [x] 4.1 Add unit tests for target remapping participants, including unresolved actual bookmarks.
-- [x] 4.2 Add unit tests for reference parameter participants with parameter name lookup and non-reference parameter omission.
-- [x] 4.3 Add unit tests for result participant visibility only after successful replay.
-- [x] 4.4 Run focused command log applib tests for replayable command mapping and participant behaviour.
-- [x] 4.5 Run `openspec validate show-replayable-participants --strict`.
diff --git a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/.openspec.yaml b/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/.openspec.yaml
deleted file mode 100644
index 11967fcb6a7..00000000000
--- a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-07
diff --git a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/design.md b/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/design.md
deleted file mode 100644
index 158e0b7b2b1..00000000000
--- a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/design.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## Context
-
-`ReplayableCommandParticipant` is a view model whose current memento includes interaction id, role, parameter name, recorded bookmark, and actual bookmark.
-The bookmark data is already derived from the owning replayable command's `CommandLogEntry` and replay mapping lookups.
-Including that derived data in the memento makes URLs noisy and can make stale bookmark values appear canonical.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Use compact readable mementos based on command interaction id and participant identity.
-- Recompute recorded bookmark, actual bookmark, and object links from the owning command log entry.
-- Keep the public view model constructor shape valid with the string memento first and injected services after it.
-- Inject `CommandLogEntryRepository` into the view model constructor if that is the simplest way to rehydrate participant state.
-- Preserve existing participant UI behaviour after rehydration.
-
-**Non-Goals:**
-
-- Do not change the participants collection content or ordering.
-- Do not change replay mapping SPI signatures.
-- Do not persist participant rows independently.
-- Do not retain the old pipe-delimited bookmark-bearing memento format as the canonical URL format.
-
-## Decisions
-
-- Use `--` as the memento delimiter because the requested forms are readable and map directly to participant roles.
-- Encode target and result participants as `[commandInteractionId]--target` and `[commandInteractionId]--result` because each command has at most one semantic target participant set and one result participant in the current UI contract.
-- Encode parameter participants as `[commandInteractionId]--parameter--[parameterName]` because the parameter name distinguishes reference parameter participants.
-- Rehydrate by loading the owning `CommandLogEntry` and selecting the matching participant from the replayable command's derived participant list.
-- Keep non-public construction helpers available for tests and collection derivation, but ensure the framework-facing constructor remains a single public constructor with memento string first.
-
-## Risks / Trade-offs
-
-- Parameter names that contain `--` could make a plain split ambiguous → Parse only the first two delimiters or preserve the remaining suffix as the parameter name.
-- Old URLs that include bookmark data will not be canonical → Treat this as a breaking URL-format refinement.
-- Rehydration adds a repository lookup for standalone participant URLs → Keep collection-derived construction direct and use repository lookup only for memento reconstruction.
diff --git a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/proposal.md b/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/proposal.md
deleted file mode 100644
index 6c847ebb87d..00000000000
--- a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/proposal.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Why
-
-`ReplayableCommandParticipant` currently serializes bookmark details into its view-model memento, making generated URLs hard to read and duplicating information that can be derived from the owning replayable command.
-Using a compact role-based memento keeps URLs readable while ensuring bookmark values remain calculated from the command log entry as source of truth.
-
-## What Changes
-
-- Change `ReplayableCommandParticipant` mementos to use readable role-based forms:
- - `[commandInteractionId]--target`
- - `[commandInteractionId]--parameter--[parameterName]`
- - `[commandInteractionId]--result`
-- Stop serializing recorded and actual bookmark values in the participant memento.
-- Rehydrate participant bookmark data by looking up the owning command log entry by command interaction id.
-- Inject `CommandLogEntryRepository` into the view model constructor if needed to support memento rehydration.
-- Preserve participant display behaviour for recorded bookmarks, actual bookmarks, object links, title, parent link, and role-specific visibility.
-- **BREAKING**: Existing URLs that use the old pipe-delimited participant memento format will no longer be the canonical participant URL format.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `replayable-command-remappings`: Simplify replayable command participant mementos and derive bookmark data from the owning replayable command.
-
-## Impact
-
-- Affects the command log applib replay participant view model memento format and constructor dependencies.
-- Affects participant derivation and tests around memento round-tripping.
-- Does not affect replay mapping SPI signatures or persistence schema.
diff --git a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/specs/replayable-command-remappings/spec.md b/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/specs/replayable-command-remappings/spec.md
deleted file mode 100644
index 3c0861d004e..00000000000
--- a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/specs/replayable-command-remappings/spec.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Replayable command participant mementos are readable and derived
-The `ReplayableCommandParticipant` view model SHALL use a readable memento based on the owning command interaction id and participant identity.
-A target participant memento SHALL use the form `[commandInteractionId]--target`.
-A parameter participant memento SHALL use the form `[commandInteractionId]--parameter--[parameterName]`.
-A result participant memento SHALL use the form `[commandInteractionId]--result`.
-The participant memento MUST NOT include recorded bookmark or actual bookmark values.
-When a participant is reconstructed from its memento, the system SHALL derive recorded bookmark, actual bookmark, and object link values from the owning replayable command and command log entry.
-The participant view model constructor used by the framework SHALL accept the string memento as its first parameter and injected services after it.
-
-#### Scenario: Target participant has readable memento
-- **WHEN** a replayable command participant has command interaction id `11111111-1111-1111-1111-111111111111` and role `TARGET`
-- **THEN** the participant memento is `11111111-1111-1111-1111-111111111111--target`
-- **AND** the memento does not contain recorded or actual bookmark values
-
-#### Scenario: Parameter participant has readable memento
-- **WHEN** a replayable command participant has command interaction id `11111111-1111-1111-1111-111111111111`, role `PARAMETER`, and parameter name `customer`
-- **THEN** the participant memento is `11111111-1111-1111-1111-111111111111--parameter--customer`
-- **AND** the memento does not contain recorded or actual bookmark values
-
-#### Scenario: Result participant has readable memento
-- **WHEN** a replayable command participant has command interaction id `11111111-1111-1111-1111-111111111111` and role `RESULT`
-- **THEN** the participant memento is `11111111-1111-1111-1111-111111111111--result`
-- **AND** the memento does not contain recorded or actual bookmark values
-
-#### Scenario: Participant rehydrates derived bookmarks from memento
-- **WHEN** a replayable command participant is reconstructed from a readable memento
-- **AND** the owning command log entry can be found by command interaction id
-- **THEN** the participant exposes the same recorded bookmark, actual bookmark, and object link values as the matching participant derived from the owning replayable command
-
-#### Scenario: View model constructor uses framework-compatible parameter order
-- **WHEN** the framework reconstructs a replayable command participant view model
-- **THEN** the constructor accepts the string memento first
-- **AND** injected services follow the string memento parameter
diff --git a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/tasks.md b/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/tasks.md
deleted file mode 100644
index 6d54dbd52d7..00000000000
--- a/openspec/changes/archive/2026-06-07-simplify-replayable-command-participant-memento/tasks.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## 1. Memento Format
-
-- [x] 1.1 Change `ReplayableCommandParticipant#viewModelMemento()` to emit `[commandInteractionId]--target` for target participants.
-- [x] 1.2 Change `ReplayableCommandParticipant#viewModelMemento()` to emit `[commandInteractionId]--parameter--[parameterName]` for parameter participants.
-- [x] 1.3 Change `ReplayableCommandParticipant#viewModelMemento()` to emit `[commandInteractionId]--result` for result participants.
-- [x] 1.4 Ensure participant mementos do not include recorded bookmark or actual bookmark values.
-
-## 2. Memento Rehydration
-
-- [x] 2.1 Keep the framework-facing view model constructor in the form `String memento` first, injected services after.
-- [x] 2.2 Inject `CommandLogEntryRepository` or another minimal collaborator needed to find the owning command log entry by interaction id.
-- [x] 2.3 Reconstruct target, parameter, and result participants from the owning replayable command's derived participant data.
-- [x] 2.4 Preserve recorded bookmark, actual bookmark, object link, title, parent link, and role-specific visibility behaviour after reconstruction.
-- [x] 2.5 Parse parameter mementos without losing parameter names that contain delimiter-like text.
-
-## 3. Tests and Validation
-
-- [x] 3.1 Add focused tests for target, parameter, and result memento strings.
-- [x] 3.2 Add focused tests that reconstruct participants from mementos and verify derived bookmark values.
... 13494 lines suppressed ...