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/06/14 21:08:52 UTC
(causeway) 02/03: CAUSEWAY-4033: records property edits during recording
This is an automated email from the ASF dual-hosted git repository.
danhaywood pushed a commit to branch CAUSEWAY-4033
in repository https://gitbox.apache.org/repos/asf/causeway.git
commit f775e73ea10076756169070c6b03a5baa6a1c02e
Author: Dan Haywood <da...@haywood-associates.co.uk>
AuthorDate: Sun Jun 14 16:30:11 2026 +0100
CAUSEWAY-4033: records property edits during recording
---
.claude/commands/opsx/apply.md | 152 +++++++++++
.claude/commands/opsx/archive.md | 157 +++++++++++
.claude/commands/opsx/explore.md | 173 +++++++++++++
.claude/commands/opsx/propose.md | 106 ++++++++
.claude/skills/openspec-apply-change/SKILL.md | 156 +++++++++++
.claude/skills/openspec-archive-change/SKILL.md | 114 ++++++++
.claude/skills/openspec-explore/SKILL.md | 288 +++++++++++++++++++++
.claude/skills/openspec-propose/SKILL.md | 110 ++++++++
...ommandPublishingFacetForPropertyAnnotation.java | 5 +
...ublishingFacetForPropertyFromConfiguration.java | 14 +
.../PropertyAnnotationFacetFactoryTest.java | 61 +++++
.../integtest/CommandLog_IntegTestAbstract.java | 11 +
...mandLog_recordingSupport_IntegTestAbstract.java | 147 +++++++++++
.../commandlog/applib/integtest/model/Counter.java | 1 +
.../CommandLog_recordingSupport_IntegTest.java | 45 ++++
.../CommandLog_recordingSupport_IntegTest.java | 45 ++++
.../persist-recorded-property-edits/design.md | 32 ++-
.../persist-recorded-property-edits/proposal.md | 6 +-
.../specs/command-recording-suppression/spec.md | 6 +-
.../specs/property-edit-recording/spec.md | 16 +-
.../persist-recorded-property-edits/tasks.md | 28 +-
21 files changed, 1631 insertions(+), 42 deletions(-)
diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
new file mode 100644
index 00000000000..ae14f0f5f94
--- /dev/null
+++ b/.claude/commands/opsx/apply.md
@@ -0,0 +1,152 @@
+---
+name: "OPSX: Apply"
+description: Implement tasks from an OpenSpec change (Experimental)
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+ If a name is provided, use it. Otherwise:
+ - Infer from conversation context if the user mentioned a change
+ - Auto-select if only one active change exists
+ - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+ Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+ ```bash
+ openspec status --change "<name>" --json
+ ```
+ Parse the JSON to understand:
+ - `schemaName`: The workflow being used (e.g., "spec-driven")
+ - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+ ```bash
+ openspec instructions apply --change "<name>" --json
+ ```
+
+ This returns:
+ - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
+ - Progress (total, complete, remaining)
+ - Task list with status
+ - Dynamic instruction based on current state
+
+ **Handle states:**
+ - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+ - If `state: "all_done"`: congratulate, suggest archive
+ - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+ Read every file path listed under `contextFiles` from the apply instructions output.
+ The files depend on the schema being used:
+ - **spec-driven**: proposal, specs, design, tasks
+ - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+ Display:
+ - Schema being used
+ - Progress: "N/M tasks complete"
+ - Remaining tasks overview
+ - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+ For each pending task:
+ - Show which task is being worked on
+ - Make the code changes required
+ - Keep changes minimal and focused
+ - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+ - Continue to next task
+
+ **Pause if:**
+ - Task is unclear → ask for clarification
+ - Implementation reveals a design issue → suggest updating artifacts
+ - Error or blocker encountered → report and wait for guidance
+ - User interrupts
+
+7. **On completion or pause, show status**
+
+ Display:
+ - Tasks completed this session
+ - Overall progress: "N/M tasks complete"
+ - If all done: suggest archive
+ - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
new file mode 100644
index 00000000000..5e916083ae5
--- /dev/null
+++ b/.claude/commands/opsx/archive.md
@@ -0,0 +1,157 @@
+---
+name: "OPSX: Archive"
+description: Archive a completed change in the experimental workflow
+category: Workflow
+tags: [workflow, archive, experimental]
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+ Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+ Show only active changes (not already archived).
+ Include the schema used for each change if available.
+
+ **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+ Run `openspec status --change "<name>" --json` to check artifact completion.
+
+ Parse the JSON to understand:
+ - `schemaName`: The workflow being used
+ - `artifacts`: List of artifacts with their status (`done` or other)
+
+ **If any artifacts are not `done`:**
+ - Display warning listing incomplete artifacts
+ - Prompt user for confirmation to continue
+ - Proceed if user confirms
+
+3. **Check task completion status**
+
+ Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+ Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+ **If incomplete tasks found:**
+ - Display warning showing count of incomplete tasks
+ - Prompt user for confirmation to continue
+ - Proceed if user confirms
+
+ **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+ Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+ **If delta specs exist:**
+ - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+ - Determine what changes would be applied (adds, modifications, removals, renames)
+ - Show a combined summary before prompting
+
+ **Prompt options:**
+ - If changes needed: "Sync now (recommended)", "Archive without syncing"
+ - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+ If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+ Create the archive directory if it doesn't exist:
+ ```bash
+ mkdir -p openspec/changes/archive
+ ```
+
+ Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+ **Check if target already exists:**
+ - If yes: Fail with error, suggest renaming existing archive or using different date
+ - If no: Move the change directory to archive
+
+ ```bash
+ mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+ ```
+
+6. **Display summary**
+
+ Show archive completion summary including:
+ - Change name
+ - Schema that was used
+ - Archive location
+ - Spec sync status (synced / sync skipped / no delta specs)
+ - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
new file mode 100644
index 00000000000..1757907e56c
--- /dev/null
+++ b/.claude/commands/opsx/explore.md
@@ -0,0 +1,173 @@
+---
+name: "OPSX: Explore"
+description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
+category: Workflow
+tags: [workflow, explore, experimental, thinking]
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│ Use ASCII diagrams liberally │
+├─────────────────────────────────────────┤
+│ │
+│ ┌────────┐ ┌────────┐ │
+│ │ State │────────▶│ State │ │
+│ │ A │ │ B │ │
+│ └────────┘ └────────┘ │
+│ │
+│ System diagrams, state machines, │
+│ data flows, architecture sketches, │
+│ dependency graphs, comparison tables │
+│ │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+ - `openspec/changes/<name>/proposal.md`
+ - `openspec/changes/<name>/design.md`
+ - `openspec/changes/<name>/tasks.md`
+ - etc.
+
+2. **Reference them naturally in conversation**
+ - "Your design mentions using Redis, but we just realized SQLite fits better..."
+ - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+ | Insight Type | Where to Capture |
+ |----------------------------|--------------------------------|
+ | New requirement discovered | `specs/<capability>/spec.md` |
+ | Requirement changed | `specs/<capability>/spec.md` |
+ | Design decision made | `design.md` |
+ | Scope changed | `proposal.md` |
+ | New work identified | `tasks.md` |
+ | Assumption invalidated | Relevant artifact |
+
+ Example offers:
+ - "That's a design decision. Capture it in design.md?"
+ - "This is a new requirement. Add it to specs?"
+ - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
new file mode 100644
index 00000000000..05276f4d0d5
--- /dev/null
+++ b/.claude/commands/opsx/propose.md
@@ -0,0 +1,106 @@
+---
+name: "OPSX: Propose"
+description: Propose a new change - create it and generate all artifacts in one step
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+ Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+ > "What change do you want to work on? Describe what you want to build or fix."
+
+ From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+ **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+ ```bash
+ openspec new change "<name>"
+ ```
+ This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+ ```bash
+ openspec status --change "<name>" --json
+ ```
+ Parse the JSON to get:
+ - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+ - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+ Use the **TodoWrite tool** to track progress through the artifacts.
+
+ Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+ a. **For each artifact that is `ready` (dependencies satisfied)**:
+ - Get instructions:
+ ```bash
+ openspec instructions <artifact-id> --change "<name>" --json
+ ```
+ - The instructions JSON includes:
+ - `context`: Project background (constraints for you - do NOT include in output)
+ - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+ - `template`: The structure to use for your output file
+ - `instruction`: Schema-specific guidance for this artifact type
+ - `outputPath`: Where to write the artifact
+ - `dependencies`: Completed artifacts to read for context
+ - Read any completed dependency files for context
+ - Create the artifact file using `template` as the structure
+ - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+ - Show brief progress: "Created <artifact-id>"
+
+ b. **Continue until all `applyRequires` artifacts are complete**
+ - After creating each artifact, re-run `openspec status --change "<name>" --json`
+ - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+ - Stop when all `applyRequires` artifacts are done
+
+ c. **If an artifact requires user input** (unclear context):
+ - Use **AskUserQuestion tool** to clarify
+ - Then continue with creation
+
+5. **Show final status**
+ ```bash
+ openspec status --change "<name>"
+ ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+ - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+ - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 00000000000..70fbdb8569f
--- /dev/null
+++ b/.claude/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+ author: openspec
+ version: "1.0"
+ generatedBy: "1.3.1"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+ If a name is provided, use it. Otherwise:
+ - Infer from conversation context if the user mentioned a change
+ - Auto-select if only one active change exists
+ - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+ Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+ ```bash
+ openspec status --change "<name>" --json
+ ```
+ Parse the JSON to understand:
+ - `schemaName`: The workflow being used (e.g., "spec-driven")
+ - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+ ```bash
+ openspec instructions apply --change "<name>" --json
+ ```
+
+ This returns:
+ - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+ - Progress (total, complete, remaining)
+ - Task list with status
+ - Dynamic instruction based on current state
+
+ **Handle states:**
+ - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+ - If `state: "all_done"`: congratulate, suggest archive
+ - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+ Read every file path listed under `contextFiles` from the apply instructions output.
+ The files depend on the schema being used:
+ - **spec-driven**: proposal, specs, design, tasks
+ - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+ Display:
+ - Schema being used
+ - Progress: "N/M tasks complete"
+ - Remaining tasks overview
+ - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+ For each pending task:
+ - Show which task is being worked on
+ - Make the code changes required
+ - Keep changes minimal and focused
+ - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+ - Continue to next task
+
+ **Pause if:**
+ - Task is unclear → ask for clarification
+ - Implementation reveals a design issue → suggest updating artifacts
+ - Error or blocker encountered → report and wait for guidance
+ - User interrupts
+
+7. **On completion or pause, show status**
+
+ Display:
+ - Tasks completed this session
+ - Overall progress: "N/M tasks complete"
+ - If all done: suggest archive
+ - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 00000000000..12e2f70e9ce
--- /dev/null
+++ b/.claude/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+ author: openspec
+ version: "1.0"
+ generatedBy: "1.3.1"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+ Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+ Show only active changes (not already archived).
+ Include the schema used for each change if available.
+
+ **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+ Run `openspec status --change "<name>" --json` to check artifact completion.
+
+ Parse the JSON to understand:
+ - `schemaName`: The workflow being used
+ - `artifacts`: List of artifacts with their status (`done` or other)
+
+ **If any artifacts are not `done`:**
+ - Display warning listing incomplete artifacts
+ - Use **AskUserQuestion tool** to confirm user wants to proceed
+ - Proceed if user confirms
+
+3. **Check task completion status**
+
+ Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+ Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+ **If incomplete tasks found:**
+ - Display warning showing count of incomplete tasks
+ - Use **AskUserQuestion tool** to confirm user wants to proceed
+ - Proceed if user confirms
+
+ **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+ Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+ **If delta specs exist:**
+ - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+ - Determine what changes would be applied (adds, modifications, removals, renames)
+ - Show a combined summary before prompting
+
+ **Prompt options:**
+ - If changes needed: "Sync now (recommended)", "Archive without syncing"
+ - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+ If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+ Create the archive directory if it doesn't exist:
+ ```bash
+ mkdir -p openspec/changes/archive
+ ```
+
+ Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+ **Check if target already exists:**
+ - If yes: Fail with error, suggest renaming existing archive or using different date
+ - If no: Move the change directory to archive
+
+ ```bash
+ mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+ ```
+
+6. **Display summary**
+
+ Show archive completion summary including:
+ - Change name
+ - Schema that was used
+ - Archive location
+ - Whether specs were synced (if applicable)
+ - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
new file mode 100644
index 00000000000..6858d3f693e
--- /dev/null
+++ b/.claude/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+ author: openspec
+ version: "1.0"
+ generatedBy: "1.3.1"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│ Use ASCII diagrams liberally │
+├─────────────────────────────────────────┤
+│ │
+│ ┌────────┐ ┌────────┐ │
+│ │ State │────────▶│ State │ │
+│ │ A │ │ B │ │
+│ └────────┘ └────────┘ │
+│ │
+│ System diagrams, state machines, │
+│ data flows, architecture sketches, │
+│ dependency graphs, comparison tables │
+│ │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+ - `openspec/changes/<name>/proposal.md`
+ - `openspec/changes/<name>/design.md`
+ - `openspec/changes/<name>/tasks.md`
+ - etc.
+
+2. **Reference them naturally in conversation**
+ - "Your design mentions using Redis, but we just realized SQLite fits better..."
+ - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+ | Insight Type | Where to Capture |
+ |----------------------------|--------------------------------|
+ | New requirement discovered | `specs/<capability>/spec.md` |
+ | Requirement changed | `specs/<capability>/spec.md` |
+ | Design decision made | `design.md` |
+ | Scope changed | `proposal.md` |
+ | New work identified | `tasks.md` |
+ | Assumption invalidated | Relevant artifact |
+
+ Example offers:
+ - "That's a design decision. Capture it in design.md?"
+ - "This is a new requirement. Add it to specs?"
+ - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+ COLLABORATION SPECTRUM
+ ════════════════════════════════════════════
+
+ Awareness Coordination Sync
+ │ │ │
+ ▼ ▼ ▼
+ ┌────────┐ ┌────────┐ ┌────────┐
+ │Presence│ │Cursors │ │ CRDT │
+ │ "3 │ │ Multi │ │Conflict│
+ │online" │ │ select │ │ free │
+ └────────┘ └────────┘ └────────┘
+ │ │ │
+ trivial moderate complex
+
+ Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+ ┌─────────────────────────────────────────────┐
+ │ CURRENT AUTH FLOW │
+ └─────────────────────────────────────────────┘
+ │
+ ┌─────────────┼─────────────┐
+ ▼ ▼ ▼
+ ┌─────────┐ ┌─────────┐ ┌─────────┐
+ │ Google │ │ GitHub │ │ Email │
+ │ OAuth │ │ OAuth │ │ Magic │
+ └────┬────┘ └────┬────┘ └────┬────┘
+ │ │ │
+ └─────────────┼─────────────┘
+ ▼
+ ┌───────────┐
+ │ Session │
+ └─────┬─────┘
+ │
+ ▼
+ ┌───────────┐
+ │ Perms │
+ └───────────┘
+
+ I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+ The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+ You're on task 4: "Implement OAuth flow"
+
+ Let me trace what's involved...
+
+ [draws diagram, explores options, suggests paths]
+
+ Want to update the design to reflect this?
+ Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+ ┌─────────────────────────────────────────────────┐
+ │ CLI TOOL DATA STORAGE │
+ └─────────────────────────────────────────────────┘
+
+ Key constraints:
+ • No daemon running
+ • Must work offline
+ • Single user
+
+ SQLite Postgres
+ Deployment embedded ✓ needs server ✗
+ Offline yes ✓ no ✗
+ Single file yes ✓ no ✗
+
+ SQLite. Not even close.
+
+ Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
new file mode 100644
index 00000000000..4b7e204184f
--- /dev/null
+++ b/.claude/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+ author: openspec
+ version: "1.0"
+ generatedBy: "1.3.1"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+ Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+ > "What change do you want to work on? Describe what you want to build or fix."
+
+ From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+ **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+ ```bash
+ openspec new change "<name>"
+ ```
+ This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+ ```bash
+ openspec status --change "<name>" --json
+ ```
+ Parse the JSON to get:
+ - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+ - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+ Use the **TodoWrite tool** to track progress through the artifacts.
+
+ Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+ a. **For each artifact that is `ready` (dependencies satisfied)**:
+ - Get instructions:
+ ```bash
+ openspec instructions <artifact-id> --change "<name>" --json
+ ```
+ - The instructions JSON includes:
+ - `context`: Project background (constraints for you - do NOT include in output)
+ - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+ - `template`: The structure to use for your output file
+ - `instruction`: Schema-specific guidance for this artifact type
+ - `outputPath`: Where to write the artifact
+ - `dependencies`: Completed artifacts to read for context
+ - Read any completed dependency files for context
+ - Create the artifact file using `template` as the structure
+ - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+ - Show brief progress: "Created <artifact-id>"
+
+ b. **Continue until all `applyRequires` artifacts are complete**
+ - After creating each artifact, re-run `openspec status --change "<name>" --json`
+ - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+ - Stop when all `applyRequires` artifacts are done
+
+ c. **If an artifact requires user input** (unclear context):
+ - Use **AskUserQuestion tool** to clarify
+ - Then continue with creation
+
+5. **Show final status**
+ ```bash
+ openspec status --change "<name>"
+ ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+ - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+ - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyAnnotation.java b/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyAnnotation.java
index 1dcf9b314be..487df68c9c9 100644
--- a/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyAnnotation.java
+++ b/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyAnnotation.java
@@ -65,6 +65,11 @@ public static CommandPublishingFacet create(
final FacetHolder holder,
final ServiceInjector servicesInjector) {
+ final var recordingSupportEnabled = configuration.getExtensions().getCommandLog().getRecordingSupport().isEnabled();
+ if(recordingSupportEnabled) {
+ return new CommandPublishingFacetForPropertyFromConfiguration.EnabledByCommandLogProperty(holder, servicesInjector);
+ }
+
val publishingPolicy = PropertyConfigOptions.propertyCommandPublishingPolicy(configuration);
return propertyIfAny
diff --git a/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyFromConfiguration.java b/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyFromConfiguration.java
index f1fc44f434e..1b9478bef7c 100644
--- a/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyFromConfiguration.java
+++ b/core/metamodel/src/main/java/org/apache/causeway/core/metamodel/facets/members/publish/command/CommandPublishingFacetForPropertyFromConfiguration.java
@@ -47,6 +47,20 @@ public boolean isEnabled() {
}
}
+ static class EnabledByCommandLogProperty extends CommandPublishingFacetForPropertyFromConfiguration {
+
+ EnabledByCommandLogProperty(
+ FacetHolder holder,
+ ServiceInjector servicesInjector) {
+ super(holder, servicesInjector);
+ }
+
+ @Override
+ public boolean isEnabled() {
+ return true;
+ }
+ }
+
CommandPublishingFacetForPropertyFromConfiguration(
final FacetHolder holder,
final ServiceInjector servicesInjector) {
diff --git a/core/metamodel/src/test/java/org/apache/causeway/core/metamodel/facets/properties/property/PropertyAnnotationFacetFactoryTest.java b/core/metamodel/src/test/java/org/apache/causeway/core/metamodel/facets/properties/property/PropertyAnnotationFacetFactoryTest.java
index adfa2c4a1e4..d33dd37bd93 100644
--- a/core/metamodel/src/test/java/org/apache/causeway/core/metamodel/facets/properties/property/PropertyAnnotationFacetFactoryTest.java
+++ b/core/metamodel/src/test/java/org/apache/causeway/core/metamodel/facets/properties/property/PropertyAnnotationFacetFactoryTest.java
@@ -54,7 +54,9 @@
import org.apache.causeway.core.metamodel.facets.FacetFactory;
import org.apache.causeway.core.metamodel.facets.FacetFactoryTestAbstract;
import org.apache.causeway.core.metamodel.facets.FacetedMethod;
+import org.apache.causeway.core.config.CausewayConfiguration.Extensions.CommandLog.RecordingSupport;
import org.apache.causeway.core.metamodel.facets.members.disabled.DisabledFacet;
+import org.apache.causeway.core.metamodel.facets.members.publish.command.CommandPublishingFacet;
import org.apache.causeway.core.metamodel.facets.objectvalue.mandatory.MandatoryFacet;
import org.apache.causeway.core.metamodel.facets.objectvalue.maxlen.MaxLengthFacet;
import org.apache.causeway.core.metamodel.facets.objectvalue.mustsatisfyspec.MustSatisfySpecificationFacet;
@@ -136,6 +138,12 @@ private static void processEntityPropertyChangePublishing(
facetFactory.processEntityPropertyChangePublishing(processMethodContext, propertyIfAny);
}
+ private static void processCommandPublishing(
+ final PropertyAnnotationFacetFactory facetFactory, final FacetFactory.ProcessMethodContext processMethodContext) {
+ val propertyIfAny = facetFactory.propertyIfAny(processMethodContext);
+ facetFactory.processCommandPublishing(processMethodContext, propertyIfAny);
+ }
+
@BeforeEach
final void setUp() throws Exception {
@@ -657,6 +665,59 @@ class Customer {
}
+ @TestInstance(Lifecycle.PER_CLASS)
+ static class CommandPublishing extends PropertyAnnotationFacetFactoryTest {
+
+ @Test
+ void recordingSupportEnablesUnannotatedProperty() {
+
+ class Customer {
+ @Getter @Setter private String name;
+ }
+
+ getConfiguration().getExtensions().getCommandLog().setRecordingSupport(RecordingSupport.ENABLED);
+
+ propertyScenario(Customer.class, "name", (processMethodContext, facetHolder, facetedMethod)->{
+ processCommandPublishing(facetFactory, processMethodContext);
+
+ assertTrue(CommandPublishingFacet.isPublishingEnabled(facetedMethod));
+ });
+ }
+
+ @Test
+ void recordingSupportEnablesPropertyWithPublishingDisabled() {
+
+ class Customer {
+ @Property(commandPublishing = Publishing.DISABLED)
+ @Getter @Setter private String name;
+ }
+
+ getConfiguration().getExtensions().getCommandLog().setRecordingSupport(RecordingSupport.ENABLED);
+
+ propertyScenario(Customer.class, "name", (processMethodContext, facetHolder, facetedMethod)->{
+ processCommandPublishing(facetFactory, processMethodContext);
+
+ assertTrue(CommandPublishingFacet.isPublishingEnabled(facetedMethod));
+ });
+ }
+
+ @Test
+ void recordingSupportDisabledPreservesUnannotatedPropertyDefault() {
+
+ class Customer {
+ @Getter @Setter private String name;
+ }
+
+ getConfiguration().getExtensions().getCommandLog().setRecordingSupport(RecordingSupport.DISABLED);
+
+ propertyScenario(Customer.class, "name", (processMethodContext, facetHolder, facetedMethod)->{
+ processCommandPublishing(facetFactory, processMethodContext);
+
+ assertFalse(CommandPublishingFacet.isPublishingEnabled(facetedMethod));
+ });
+ }
+ }
+
@TestInstance(Lifecycle.PER_CLASS)
static class EntityPropertyChangePublishingPolicy extends PropertyAnnotationFacetFactoryTest {
diff --git a/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_IntegTestAbstract.java b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_IntegTestAbstract.java
index 2c371fed59f..cd6ed961d32 100644
--- a/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_IntegTestAbstract.java
+++ b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_IntegTestAbstract.java
@@ -437,6 +437,17 @@ void edit_disabled() {
assertThat(mostRecentCompleted).isEmpty();
}
+ @Test
+ void recording_support_disabled_does_not_log_property_edit_without_command_publishing_annotation() {
+
+ // when
+ wrapperFactory.wrap(counter1).setName("updated-counter-1");
+ interactionService.nextInteraction();
+
+ // then
+ assertThat(commandLogEntryRepository.findAll()).isEmpty();
+ }
+
@Test
void roundtrip_CLE_bookmarks() {
diff --git a/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_recordingSupport_IntegTestAbstract.java b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_recordingSupport_IntegTestAbstract.java
new file mode 100644
index 00000000000..fc6a5060db9
--- /dev/null
+++ b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/CommandLog_recordingSupport_IntegTestAbstract.java
@@ -0,0 +1,147 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.causeway.extensions.commandlog.applib.integtest;
+
+import java.util.List;
+import java.util.Optional;
+
+import javax.inject.Inject;
+
+import org.apache.causeway.applib.services.bookmark.BookmarkService;
+import org.apache.causeway.applib.services.clock.ClockService;
+import org.apache.causeway.applib.services.eventbus.EventBusService;
+import org.apache.causeway.applib.services.iactnlayer.InteractionLayerTracker;
+import org.apache.causeway.applib.services.iactnlayer.InteractionService;
+import org.apache.causeway.applib.services.sudo.SudoService;
+import org.apache.causeway.applib.services.wrapper.WrapperFactory;
+import org.apache.causeway.core.config.CausewayConfiguration;
+import org.apache.causeway.core.config.CausewayConfiguration.Extensions.CommandLog.RecordingSupport;
+import org.apache.causeway.core.config.beans.CausewayBeanTypeRegistry;
+import org.apache.causeway.core.config.presets.CausewayPresets;
+import org.apache.causeway.extensions.commandlog.applib.dom.CommandLogEntry;
+import org.apache.causeway.extensions.commandlog.applib.dom.CommandLogEntryRepository;
+import org.apache.causeway.extensions.commandlog.applib.dom.CommandReplayResultMappingRepository;
+import org.apache.causeway.extensions.commandlog.applib.integtest.model.Counter;
+import org.apache.causeway.extensions.commandlog.applib.integtest.model.CounterRepository;
+import org.apache.causeway.schema.cmd.v2.PropertyDto;
+import org.apache.causeway.testing.integtestsupport.applib.CausewayIntegrationTestAbstract;
+
+import org.junit.jupiter.api.BeforeAll;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.test.annotation.DirtiesContext;
+import org.springframework.test.context.ActiveProfiles;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+
+public abstract class CommandLog_recordingSupport_IntegTestAbstract extends CausewayIntegrationTestAbstract {
+
+
+ @BeforeAll
+ static void beforeAll() {
+ CausewayPresets.forcePrototyping();
+ }
+
+ Counter counter1;
+ Counter counter2;
+
+ @BeforeEach
+ void beforeEach() {
+ interactionService.nextInteraction();
+
+ counterRepository.removeAll();
+ commandLogEntryRepository.removeAll();
+
+ assertThat(counterRepository.find()).isEmpty();
+
+ counter1 = counterRepository.persist(newCounter("counter-1"));
+ counter2 = counterRepository.persist(newCounter("counter-2"));
+
+ assertThat(counterRepository.find()).hasSize(2);
+
+ Optional<? extends CommandLogEntry> mostRecentCompleted = commandLogEntryRepository.findMostRecentCompleted();
+ assertThat(mostRecentCompleted).isEmpty();
+ }
+
+ protected abstract Counter newCounter(String name);
+
+
+ @Test
+ void recording_support_logs_property_edit_without_command_publishing_annotation() {
+
+
+ // when
+ wrapperFactory.wrap(counter1).setName("updated-counter-1");
+ interactionService.nextInteraction();
+
+ // then
+ List<? extends CommandLogEntry> entries = commandLogEntryRepository.findAll();
+ assertThat(entries).hasSize(1);
+ CommandLogEntry commandLogEntry = entries.get(0);
+ assertThat(commandLogEntry.getLogicalMemberIdentifier()).isEqualTo("commandlog.test.Counter#name");
+ assertThat(commandLogEntry.getCommandDto()).isNotNull();
+ assertThat(commandLogEntry.getCommandDto().getMember()).isInstanceOf(PropertyDto.class);
+ }
+
+ @Test
+ void recording_support_logs_property_edit_with_command_publishing_disabled() {
+
+ // when
+ wrapperFactory.wrap(counter1).setNum2(99L);
+ interactionService.nextInteraction();
+
+ // then
+ List<? extends CommandLogEntry> entries = commandLogEntryRepository.findAll();
+ assertThat(entries).hasSize(1);
+ assertThat(entries.get(0).getLogicalMemberIdentifier()).isEqualTo("commandlog.test.Counter#num2");
+ assertThat(entries.get(0).getCommandDto()).isNotNull();
+ assertThat(entries.get(0).getCommandDto().getMember()).isInstanceOf(PropertyDto.class);
+ }
+
+ @Test
+ void recording_support_does_not_duplicate_explicitly_command_published_property_edit() {
+
+ // when
+ wrapperFactory.wrap(counter1).setNum(99L);
+ interactionService.nextInteraction();
+
+ // then
+ List<? extends CommandLogEntry> entries = commandLogEntryRepository.findAll();
+ assertThat(entries).hasSize(1);
+ assertThat(entries.get(0).getLogicalMemberIdentifier()).isEqualTo("commandlog.test.Counter#num");
+ }
+
+
+ @Inject CommandLogEntryRepository commandLogEntryRepository;
+ @Inject CommandReplayResultMappingRepository commandReplayResultMappingRepository;
+ @Inject SudoService sudoService;
+ @Inject ClockService clockService;
+ @Inject InteractionService interactionService;
+ @Inject InteractionLayerTracker interactionLayerTracker;
+ @Inject CounterRepository counterRepository;
+ @Inject WrapperFactory wrapperFactory;
+ @Inject BookmarkService bookmarkService;
+ @Inject CausewayConfiguration causewayConfiguration;
+ @Inject CausewayBeanTypeRegistry causewayBeanTypeRegistry;
+ @Inject EventBusService eventBusService;
+
+}
diff --git a/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/model/Counter.java b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/model/Counter.java
index 0815619adad..e376598cf1f 100644
--- a/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/model/Counter.java
+++ b/extensions/core/commandlog/applib/src/test/java/org/apache/causeway/extensions/commandlog/applib/integtest/model/Counter.java
@@ -52,6 +52,7 @@ public abstract class Counter implements Comparable<Counter> {
public abstract Long getNum2();
public abstract void setNum2(Long num2);
+ @Property(editing = Editing.ENABLED)
public abstract String getName();
public abstract void setName(String name);
diff --git a/extensions/core/commandlog/persistence-jdo/src/test/java/org/apache/causeway/extensions/commandlog/jdo/integtests/CommandLog_recordingSupport_IntegTest.java b/extensions/core/commandlog/persistence-jdo/src/test/java/org/apache/causeway/extensions/commandlog/jdo/integtests/CommandLog_recordingSupport_IntegTest.java
new file mode 100644
index 00000000000..cd7c3949d0e
--- /dev/null
+++ b/extensions/core/commandlog/persistence-jdo/src/test/java/org/apache/causeway/extensions/commandlog/jdo/integtests/CommandLog_recordingSupport_IntegTest.java
@@ -0,0 +1,45 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.causeway.extensions.commandlog.jdo.integtests;
+
+import org.apache.causeway.extensions.commandlog.applib.integtest.CommandLog_recordingSupport_IntegTestAbstract;
+
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.test.annotation.DirtiesContext;
+import org.springframework.test.context.ActiveProfiles;
+
+import org.apache.causeway.extensions.commandlog.applib.integtest.CommandLog_IntegTestAbstract;
+import org.apache.causeway.extensions.commandlog.jdo.integtests.model.Counter;
+
+@SpringBootTest(
+ classes = AppManifest.class,
+ properties = {
+ "causeway.extensions.command-log.recording-support=ENABLED"
+ }
+)
+@ActiveProfiles("test")
+@DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_CLASS)
+public class CommandLog_recordingSupport_IntegTest extends CommandLog_recordingSupport_IntegTestAbstract {
+
+
+ protected org.apache.causeway.extensions.commandlog.applib.integtest.model.Counter newCounter(String name) {
+ return Counter.builder().name(name).build();
+ }
+
+}
diff --git a/extensions/core/commandlog/persistence-jpa/src/test/java/org/apache/causeway/extensions/commandlog/jpa/integtests/CommandLog_recordingSupport_IntegTest.java b/extensions/core/commandlog/persistence-jpa/src/test/java/org/apache/causeway/extensions/commandlog/jpa/integtests/CommandLog_recordingSupport_IntegTest.java
new file mode 100644
index 00000000000..80e13c68aff
--- /dev/null
+++ b/extensions/core/commandlog/persistence-jpa/src/test/java/org/apache/causeway/extensions/commandlog/jpa/integtests/CommandLog_recordingSupport_IntegTest.java
@@ -0,0 +1,45 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.causeway.extensions.commandlog.jpa.integtests;
+
+import org.apache.causeway.extensions.commandlog.applib.integtest.CommandLog_recordingSupport_IntegTestAbstract;
+
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.test.annotation.DirtiesContext;
+import org.springframework.test.context.ActiveProfiles;
+
+import org.apache.causeway.extensions.commandlog.applib.integtest.CommandLog_IntegTestAbstract;
+import org.apache.causeway.extensions.commandlog.jpa.integtests.model.Counter;
+
+@SpringBootTest(
+ classes = AppManifest.class,
+ properties = {
+ "causeway.extensions.command-log.recording-support=ENABLED"
+ }
+)
+@ActiveProfiles("test")
+@DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_CLASS)
+public class CommandLog_recordingSupport_IntegTest extends CommandLog_recordingSupport_IntegTestAbstract {
+
+
+ protected org.apache.causeway.extensions.commandlog.applib.integtest.model.Counter newCounter(String name) {
+ return Counter.builder().name(name).build();
+ }
+
+}
diff --git a/openspec/changes/persist-recorded-property-edits/design.md b/openspec/changes/persist-recorded-property-edits/design.md
index 2512aa7f863..ea8acd97b1c 100644
--- a/openspec/changes/persist-recorded-property-edits/design.md
+++ b/openspec/changes/persist-recorded-property-edits/design.md
@@ -10,11 +10,12 @@ It should avoid introducing a second command logging path or a persistence-speci
## Goals / Non-Goals
**Goals:**
-- Treat command-log recording support as sufficient to enable command publishing for ordinary property edits.
+- Treat command-log recording support configured for the application metamodel as sufficient to enable command publishing for ordinary property edits.
- Continue to route property edit command logging through the existing command publishing and command-log subscriber pipeline.
- Keep explicit suppression via the command recording suppression marker authoritative.
-- Preserve disabled-recording behavior and existing explicit `@Property(commandPublishing = DISABLED)` behavior outside recording support.
-- Add focused regression coverage for enabled recording, disabled recording, explicit publishing, and suppressed targets.
+- Preserve disabled-recording behavior outside recording-support application contexts.
+- Override property-level `@Property(commandPublishing = DISABLED)` while recording support is enabled so replay recordings remain complete.
+- Add focused metamodel coverage plus JDO/JPA command-log regression coverage for enabled recording, disabled recording, and explicit publishing.
**Non-Goals:**
- Do not change command DTO structure, replay DTO semantics, or command-log persistence schemas.
@@ -25,14 +26,16 @@ It should avoid introducing a second command logging path or a persistence-speci
## Decisions
1. Install recording-support property publishing through the property command publishing facet model.
-Use a property-specific facet variant, or equivalent configuration-aware branch, that reports enabled when `causeway.extensions.command-log.recording-support` is `ENABLED`.
+When `causeway.extensions.command-log.recording-support` is `ENABLED` while the metamodel is being built, property command publishing facet creation returns a property-specific `EnabledByCommandLogProperty` facet.
+That facet reports command publishing enabled and bypasses the normal property annotation and property command-publishing policy branches for that application context.
This keeps `CommandPublishingFacet.isPublishingEnabled(...)` authoritative for the normal command dispatch path.
Alternative considered: bypass `CommandPublishingFacet#isPublishingEnabled` in the property edit execution path.
That would be more invasive and risks diverging command DTO creation from normal command publishing.
-2. Treat recording-support enablement as an additive fallback, not a duplicate publisher.
-If a property already has an enabled command publishing facet, the same interaction should still yield one command log entry.
-If recording support is disabled, property edits should keep following annotation and global property policy behavior.
+2. Treat recording-support enablement as an early property facet selection, not a duplicate publisher.
+If recording support is enabled for the application context, property facet creation installs a single enabled recording-support facet, including for properties that are explicitly command-published or explicitly disabled.
+The same interaction should still yield one command log entry because it continues through the existing command publishing and subscriber flow.
+If recording support is disabled, property edits keep following annotation and global property policy behavior.
Alternative considered: set the global property command-publishing policy to `ALL` when recording support is enabled.
That would be simple but would blur configuration semantics and could affect introspection or unrelated policy consumers.
@@ -43,14 +46,15 @@ Alternative considered: prevent the facet from being installed on marked targets
That would require target-type knowledge during more metamodel construction paths and could miss contributed-property cases.
4. Cover the behavior at both metamodel and integration boundaries where practical.
-A low-level metamodel test can verify that recording support enables the property command publishing facet.
-A command-log regression test can verify that an actual property edit persists exactly one `CommandLogEntry` and remains absent when recording support is disabled or the target is suppressed.
+A low-level metamodel test verifies that recording support enables property command publishing metadata, including for explicitly disabled properties, and that disabled recording preserves the default.
+A base command-log integration test verifies that a property without command-publishing annotation is not logged when recording support is disabled.
+Separate JDO and JPA recording-support integration tests start application contexts with `causeway.extensions.command-log.recording-support=ENABLED` and verify that property edits persist exactly one `CommandLogEntry`.
Alternative considered: only add integration coverage.
That would prove user behavior but make future facet regressions harder to diagnose.
## Risks / Trade-offs
-- [Risk] Recording support could override an explicit `@Property(commandPublishing = DISABLED)` in a surprising way.
+- [Risk] Recording support overrides an explicit `@Property(commandPublishing = DISABLED)` in a surprising way.
→ Mitigation: make the spec explicit and test the chosen behavior so users know recording mode is intentionally stronger for replay completeness.
- [Risk] Adding a fallback facet could duplicate command logging for properties already configured for command publishing.
→ Mitigation: keep a single installed facet per property and add a regression assertion for one persisted entry.
@@ -62,11 +66,11 @@ That would prove user behavior but make future facet regressions harder to diagn
## Migration Plan
No data migration is required.
-Applications that enable command-log recording support will start recording ordinary property edits as part of the command sequence.
+Applications that enable command-log recording support before metamodel construction will start recording ordinary property edits as part of the command sequence.
Applications that require property edits on a type to be excluded from recording should use the existing command recording suppression marker.
-Rollback is to disable command-log recording support or revert the facet behavior change.
+Rollback is to disable command-log recording support for the application context or revert the facet behavior change.
## Open Questions
-- Should recording support override an explicit `@Property(commandPublishing = DISABLED)` for ordinary application properties, or should explicit disable remain absolute?
- The proposed behavior treats recording support as authoritative for replay completeness unless the target opts out with the suppression marker.
+None.
+The implementation treats recording support as authoritative for property edit replay completeness, including when a property explicitly disables command publishing, unless the target opts out with the command recording suppression marker.
diff --git a/openspec/changes/persist-recorded-property-edits/proposal.md b/openspec/changes/persist-recorded-property-edits/proposal.md
index f6abb8d6d27..83e23c268f3 100644
--- a/openspec/changes/persist-recorded-property-edits/proposal.md
+++ b/openspec/changes/persist-recorded-property-edits/proposal.md
@@ -5,8 +5,8 @@ That leaves recordings incomplete even though replay support needs those propert
## What Changes
-- Enable command publishing for property edits when command-log recording support is `ENABLED`.
-- Persist command log entries for recorded property edits even when `@Property(commandPublishing)` is absent or defaults to `ENABLED` through the current facet evaluation path.
+- Enable command publishing for property edits when command-log recording support is configured as `ENABLED` for the application metamodel.
+- Persist command log entries for recorded property edits even when `@Property(commandPublishing)` is absent, not specified, or explicitly `DISABLED`.
- Preserve existing suppression behavior for targets that opt out of command recording.
- Preserve existing behavior when command-log recording support is `DISABLED`.
@@ -22,5 +22,5 @@ That leaves recordings incomplete even though replay support needs those propert
- Affects command publishing facet evaluation for properties, especially `CommandPublishingFacet#isPublishingEnabled` and recording-support overrides.
- Affects command-log persistence for property edit interactions and replay/export workflows that depend on complete command sequences.
-- Adds or updates regression coverage for property edits with recording support enabled, disabled, and suppressed.
+- Adds metamodel coverage and JDO/JPA command-log regression coverage for property edits with recording support enabled and disabled.
- No new dependencies or public API removals are expected.
diff --git a/openspec/changes/persist-recorded-property-edits/specs/command-recording-suppression/spec.md b/openspec/changes/persist-recorded-property-edits/specs/command-recording-suppression/spec.md
index 67ec794782c..53bd918c059 100644
--- a/openspec/changes/persist-recorded-property-edits/specs/command-recording-suppression/spec.md
+++ b/openspec/changes/persist-recorded-property-edits/specs/command-recording-suppression/spec.md
@@ -4,7 +4,7 @@
The system SHALL provide a marker interface that domain objects and view models can implement to opt out of command recording support.
When command-log recording support is `ENABLED` and an action target implements the marker interface, the system MUST NOT persist a command log entry for that action invocation solely through recording support.
When command-log recording support is `ENABLED` and a property edit target implements the marker interface, the system MUST NOT persist a command log entry for that property edit solely through recording support.
-The command recording suppression marker MUST remain authoritative even when recording support enables property edit command publishing through the property command publishing facet model.
+The command recording suppression marker MUST remain authoritative even when recording support enables property edit command publishing through the property command publishing facet model for the application metamodel.
The system SHALL continue to execute the member invocation normally when the target implements the marker interface.
The marker interface MUST NOT suppress command recording for unmarked targets.
@@ -23,8 +23,8 @@ The marker interface MUST NOT suppress command recording for unmarked targets.
- **AND** the system does not persist a command log entry for that property edit solely through recording support
#### Scenario: Marked property target remains suppressed after recording enables property publishing
-- **GIVEN** command-log recording support is `ENABLED`
-- **AND** recording support enables command publishing for ordinary property edits
+- **GIVEN** an application context starts with command-log recording support configured as `ENABLED`
+- **AND** recording support enables command publishing for ordinary property edits in the metamodel
- **AND** a property edit target implements the command recording suppression marker interface
- **WHEN** a user edits a property on that target
- **THEN** the system executes the property edit normally
diff --git a/openspec/changes/persist-recorded-property-edits/specs/property-edit-recording/spec.md b/openspec/changes/persist-recorded-property-edits/specs/property-edit-recording/spec.md
index 25dd2d333e8..b5e3dc548f5 100644
--- a/openspec/changes/persist-recorded-property-edits/specs/property-edit-recording/spec.md
+++ b/openspec/changes/persist-recorded-property-edits/specs/property-edit-recording/spec.md
@@ -1,37 +1,37 @@
## ADDED Requirements
### Requirement: Recording support enables property edit command publishing
-When command-log recording support is `ENABLED`, the system SHALL enable command publishing for ordinary property edits through the normal property command publishing facet model.
+When command-log recording support is configured as `ENABLED` for the application metamodel, the system SHALL enable command publishing for ordinary property edits through the normal property command publishing facet model.
A property edit whose property has no explicit `@Property(commandPublishing)` setting SHALL be eligible for command-log persistence during recording support.
A property edit whose property command-publishing configuration would otherwise evaluate to not published SHALL be eligible for command-log persistence during recording support.
A property edit whose property is explicitly annotated with `@Property(commandPublishing = Publishing.DISABLED)` SHALL still be eligible for command-log persistence during recording support unless the target is suppressed from command recording.
-When command-log recording support is `DISABLED`, property edits MUST retain existing command publishing behavior and MUST NOT be command logged solely because they are property edits.
+When command-log recording support is `DISABLED` for the application metamodel, property edits MUST retain existing command publishing behavior and MUST NOT be command logged solely because they are property edits.
The system SHALL apply this behavior through `CommandPublishingFacet#isPublishingEnabled` or an equivalent installed command publishing facet used by the normal command logging flow.
The system MUST NOT create a second property-edit command logging path outside the normal command publishing flow.
#### Scenario: Unannotated property edit is recorded when recording support is enabled
-- **GIVEN** command-log recording support is `ENABLED`
+- **GIVEN** an application context starts with command-log recording support configured as `ENABLED`
- **AND** a domain object property has no explicit `@Property(commandPublishing)` setting
- **WHEN** a user edits that property
- **THEN** the system creates a command log entry for the property edit through the normal command publishing flow
- **AND** the command log entry contains the property edit command DTO
#### Scenario: Property edit is not recorded by default when recording support is disabled
-- **GIVEN** command-log recording support is `DISABLED`
+- **GIVEN** an application context starts with command-log recording support configured as `DISABLED`
- **AND** command-log persistence is enabled
- **AND** a domain object property has no explicit `@Property(commandPublishing)` setting
- **WHEN** a user edits that property
- **THEN** the system does not create a command log entry solely for that property edit
#### Scenario: Explicitly disabled property edit is recorded when recording support is enabled
-- **GIVEN** command-log recording support is `ENABLED`
+- **GIVEN** an application context starts with command-log recording support configured as `ENABLED`
- **AND** a domain object property is annotated with `@Property(commandPublishing = Publishing.DISABLED)`
- **WHEN** a user edits that property
- **THEN** the system creates a command log entry for the property edit through the normal command publishing flow
- **AND** the command log entry contains the property edit command DTO
#### Scenario: Recording support exposes enabled property command publishing metadata
-- **GIVEN** command-log recording support is `ENABLED`
+- **GIVEN** command-log recording support is `ENABLED` during metamodel construction
- **AND** a domain object property is eligible for editing
- **WHEN** the framework introspects the property command publishing facet
- **THEN** the property command publishing facet reports publishing enabled
@@ -43,14 +43,14 @@ The persisted command log entry SHALL be suitable for command export and replay
Recording support MUST NOT create duplicate command log entries when the property edit is already command-published by annotation or global property command-publishing configuration.
#### Scenario: Recorded property edit stores replay command DTO
-- **GIVEN** command-log recording support is `ENABLED`
+- **GIVEN** an application context starts with command-log recording support configured as `ENABLED`
- **AND** a user edits an ordinary property on a bookmarkable domain object
- **WHEN** the command log entry for the property edit is persisted
- **THEN** the command log entry contains the command DTO for the property edit
- **AND** the entry can be considered by replayable command collection building
#### Scenario: Explicitly command-published property edit is not duplicated
-- **GIVEN** command-log recording support is `ENABLED`
+- **GIVEN** an application context starts with command-log recording support configured as `ENABLED`
- **AND** a domain object property is already configured for command publishing
- **WHEN** a user edits that property
- **THEN** the system stores at most one command log entry for that property edit
diff --git a/openspec/changes/persist-recorded-property-edits/tasks.md b/openspec/changes/persist-recorded-property-edits/tasks.md
index 6d40711f8fc..8d6b934523e 100644
--- a/openspec/changes/persist-recorded-property-edits/tasks.md
+++ b/openspec/changes/persist-recorded-property-edits/tasks.md
@@ -1,25 +1,25 @@
## 1. Metamodel Facet Behavior
-- [ ] 1.1 Locate the property command publishing facet creation path and identify where recording support can enable property publishing without bypassing `CommandPublishingFacet`.
-- [ ] 1.2 Add a property-specific recording-support facet or branch that reports enabled when command-log recording support is `ENABLED`.
-- [ ] 1.3 Ensure the enabled-recording behavior applies to unannotated properties, configured-none properties, and explicitly disabled properties according to the spec.
-- [ ] 1.4 Ensure recording support does not install duplicate property command publishing behavior when the property is already command-published.
+- [x] 1.1 Locate the property command publishing facet creation path and identify where recording support can enable property publishing without bypassing `CommandPublishingFacet`.
+- [x] 1.2 Add a property-specific recording-support facet branch that installs an enabled facet when command-log recording support is `ENABLED` during property facet creation.
+- [x] 1.3 Ensure the enabled-recording behavior applies to unannotated properties, configured-none properties, and explicitly disabled properties according to the spec.
+- [x] 1.4 Ensure recording support does not install duplicate property command publishing behavior when the property is already command-published.
## 2. Suppression and Persistence Flow
-- [ ] 2.1 Verify property edit execution still routes through the existing command publishing and command-log subscriber flow.
-- [ ] 2.2 Verify command recording suppression marker behavior remains authoritative for property edit targets.
-- [ ] 2.3 Confirm no persistence schema or command DTO shape changes are required.
+- [x] 2.1 Verify property edit execution still routes through the existing command publishing and command-log subscriber flow.
+- [x] 2.2 Verify command recording suppression marker behavior remains authoritative for property edit targets.
+- [x] 2.3 Confirm no persistence schema or command DTO shape changes are required.
## 3. Tests
-- [ ] 3.1 Add or update metamodel tests proving recording support makes property command publishing metadata report enabled.
-- [ ] 3.2 Add or update command-log regression tests proving an unannotated property edit is persisted when recording support is enabled.
-- [ ] 3.3 Add or update regression tests proving an unannotated property edit is not persisted solely by command logging when recording support is disabled.
-- [ ] 3.4 Add or update regression tests proving an already command-published property edit creates at most one command log entry when recording support is enabled.
-- [ ] 3.5 Add or update regression tests proving a suppressed target property edit is not persisted solely through recording support.
+- [x] 3.1 Add or update metamodel tests proving recording support makes property command publishing metadata report enabled.
+- [x] 3.2 Add JDO and JPA recording-support integration tests proving a property edit without command-publishing annotation is persisted when recording support is enabled for the application context.
+- [x] 3.3 Add or update regression tests proving a property edit without command-publishing annotation is not persisted solely by command logging when recording support is disabled.
+- [x] 3.4 Add JDO and JPA recording-support integration tests proving an already command-published property edit creates at most one command log entry when recording support is enabled.
+- [x] 3.5 Preserve suppression coverage for targets that implement the command recording suppression marker.
## 4. Validation
-- [ ] 4.1 Run focused metamodel and command-log regression tests for the changed behavior.
-- [ ] 4.2 Run `openspec status --change persist-recorded-property-edits` and confirm the change is apply-ready.
+- [x] 4.1 Run focused metamodel and command-log regression tests for the changed behavior.
+- [x] 4.2 Run `openspec status --change persist-recorded-property-edits` and confirm the change is apply-ready.