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/04 07:50:40 UTC

(causeway) 11/11: docs(openspec): archive utility menu and Vue result fixes

This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a commit to branch htmx
in repository https://gitbox.apache.org/repos/asf/causeway.git

commit 2f0dca6a414bad77ece6ed4d19dd305f4692f101
Author: Dan Haywood <da...@haywood-associates.co.uk>
AuthorDate: Fri Sep 4 08:42:13 2026 +0100

    docs(openspec): archive utility menu and Vue result fixes
---
 .../.openspec.yaml                                 |  0
 .../design.md                                      |  0
 .../proposal.md                                    |  0
 .../generic-htmx-web-component-viewer/spec.md      |  0
 .../specs/generic-vue-web-component-viewer/spec.md |  0
 .../spec.md                                        |  0
 .../vue-viewer-local-secman-authentication/spec.md |  0
 .../tasks.md                                       |  0
 .../generic-htmx-web-component-viewer/spec.md      | 18 ++++++++
 .../specs/generic-vue-web-component-viewer/spec.md | 53 ++++++++++++++++------
 .../spec.md                                        | 15 +++---
 .../vue-viewer-local-secman-authentication/spec.md | 24 +++++++---
 12 files changed, 82 insertions(+), 28 deletions(-)

diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/.openspec.yaml b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/.openspec.yaml
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/.openspec.yaml
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/.openspec.yaml
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/design.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/design.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/design.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/design.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/proposal.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/proposal.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/proposal.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/proposal.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/specs/generic-htmx-web-component-viewer/spec.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/generic-htmx-web-component-viewer/spec.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/specs/generic-htmx-web-component-viewer/spec.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/generic-htmx-web-component-viewer/spec.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/specs/generic-vue-web-component-viewer/spec.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/generic-vue-web-component-viewer/spec.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/specs/generic-vue-web-component-viewer/spec.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/generic-vue-web-component-viewer/spec.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/specs/htmx-viewer-local-secman-authentication/spec.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/htmx-viewer-local-secman-authentication/spec.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/specs/htmx-viewer-local-secman-authentication/spec.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/htmx-viewer-local-secman-authentication/spec.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/specs/vue-viewer-local-secman-authentication/spec.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/vue-viewer-local-secman-authentication/spec.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/specs/vue-viewer-local-secman-authentication/spec.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/specs/vue-viewer-local-secman-authentication/spec.md
diff --git a/openspec/changes/fix-account-menu-and-vue-action-results/tasks.md b/openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/tasks.md
similarity index 100%
rename from openspec/changes/fix-account-menu-and-vue-action-results/tasks.md
rename to openspec/changes/archive/2026-09-04-fix-account-menu-and-vue-action-results/tasks.md
diff --git a/openspec/specs/generic-htmx-web-component-viewer/spec.md b/openspec/specs/generic-htmx-web-component-viewer/spec.md
index ffbf1d935b6..2fadf86e888 100644
--- a/openspec/specs/generic-htmx-web-component-viewer/spec.md
+++ b/openspec/specs/generic-htmx-web-component-viewer/spec.md
@@ -388,29 +388,47 @@ The viewer SHALL provide an optional responsive theme that closely follows the c
 - **AND** semantic behavior and DOM ownership remain unchanged
 
 ### Requirement: Executable Petclinic reference application
+
 The project SHALL include a deterministic current-Causeway Petclinic application ported from the documented pinned Apache source, exposing HTMX and Wicket viewers over the same domain model and using private HTML resources for all application-specific HTMX object-page composition.
+The Petclinic application menu layout SHALL expose its selected utility actions through one tertiary utility menu and SHALL NOT retain a superfluous unreferenced-action System menu or a separate fixed Account menu.
+The HTMX host SHALL label the consolidated utility menu with the authoritative current username when available, use Account only as a non-identifying fallback, and give exact Logout a distinct accessible outlined presentation.
 
 #### Scenario: Petclinic sample starts
+
 - **WHEN** the documented Maven profile launches the sample
 - **THEN** Pet Owners, Pets, Visits, object home, service actions, object actions, choices, defaults, validation, effective menus, retained effective grids, and fixture data are available through GraphQL and the HTMX viewer
 - **AND** the Wicket viewer is available at its documented comparison path over the same state
 
+#### Scenario: Petclinic utility menu loads
+
+- **WHEN** the ordinary or secured HTMX shell loads the effective application menus
+- **THEN** the selected authorized **Me**, **Configuration**, and Logout actions occupy one tertiary utility menu according to host policy
+- **AND** the menu title is the current username supplied by authoritative host context, or Account when no trustworthy display identity is available
+- **AND** no separate System or Account menu duplicates **Me** or remains empty
+- **AND** exact Logout is labelled **Sign out** and has a distinct accessible outlined or equivalently bounded treatment that adjacent actions do not inherit
+- **AND** authorization can omit an action without manufacturing another menu or action
+- **AND** title and appearance mapping do not change action identity, ordering, invocation, or CSRF-safe host ownership
+
 #### Scenario: Copied source is reviewed
+
 - **WHEN** a maintainer inspects the Petclinic sample
 - **THEN** provenance identifies repository commit `16a10608129ca9ce8ae04d21df1462f4d69ac018`, copied concepts, license, omissions, and current-API porting changes
 - **AND** obsolete starter, security, operational, and deployment infrastructure is not represented as current viewer behavior
 
 #### Scenario: Petclinic HTML page is present
+
 - **WHEN** a route addresses `petclinic.HomePage`, `petclinic.PetOwner`, `petclinic.Pet`, or `petclinic.Visit`
 - **THEN** the exact convention-registered HTML resource composes ordinary HTML and semantic components beneath one route context
 - **AND** no Petclinic Java page renderer or custom-page knowledge inside `<cw-object>` is required
 
 #### Scenario: Petclinic HTML page is absent
+
 - **WHEN** a Petclinic logical type is run without its corresponding packaged HTML resource
 - **THEN** the HTMX router uses the generic `<cw-object editable>` page
 - **AND** the retained effective grid and collection-column resources remain available for fallback composition
 
 #### Scenario: Petclinic page resources are packaged
+
 - **WHEN** the ordinary sample artifact is built and inspected
 - **THEN** all four HTML pages and all retained layout fallback resources are present at their documented private locations
 - **AND** no frontend package installation, JavaScript bundling, CDN retrieval, or executable Spring Boot repackaging is required for ordinary reactor packaging
diff --git a/openspec/specs/generic-vue-web-component-viewer/spec.md b/openspec/specs/generic-vue-web-component-viewer/spec.md
index 0f7484c4e79..1e7d113c334 100644
--- a/openspec/specs/generic-vue-web-component-viewer/spec.md
+++ b/openspec/specs/generic-vue-web-component-viewer/spec.md
@@ -198,50 +198,62 @@ Structured values and services SHALL be assigned as DOM properties rather than s
 
 ### Requirement: Vue navigation, home, and result policy
 
-The viewer SHALL provide replaceable policy for object navigation, application-entry home behavior, and scalar, object, collection, and void action results.
+The viewer SHALL provide replaceable policy for object navigation, application-entry home behavior, and scalar, object, collection, void, local-resource, and unsupported action results.
 Application handlers SHALL receive semantic payloads through a documented single-claim protocol without replacing component interaction behavior.
+For every unclaimed result, default policy SHALL perform one deterministic host handoff, dismiss transient result presentation owned by the interaction source, and prevent obsolete viewer-owned result presentation from surviving a later replacement or navigation outcome.
 
 #### Scenario: Object result uses default policy
 
-- **WHEN** an interaction returns complete navigable object identity and no application handler claims it
-- **THEN** default policy navigates to the canonical Vue object route
-- **AND** the component-provided identity remains authoritative
+- **WHEN** an interaction returns complete navigable object identity, including a view-model identity such as `UserMemento`, and no application handler claims it
+- **THEN** default policy clears obsolete viewer-owned result presentation and navigates to the canonical Vue object route
+- **AND** the component-provided logical type and opaque identifier remain authoritative
+- **AND** transient source result chrome is dismissed after handoff
 
 #### Scenario: Object result lacks navigation identity
 
 - **WHEN** an object-shaped result lacks the required public logical type or opaque identifier
-- **THEN** default policy presents a bounded unsupported result
-- **AND** does not infer identity from title, type name, current route, or Vue state
+- **THEN** default policy replaces the selected result outlet with a bounded unsupported result
+- **AND** dismisses transient source result chrome
+- **AND** does not infer identity from title, type name, action identity, current route, or Vue state
 
 #### Scenario: Non-object result uses a page outlet
 
 - **WHEN** a scalar or collection result is unclaimed and the active page declares exactly one eligible result outlet
-- **THEN** default policy assigns the normalized result to that outlet
+- **THEN** default policy assigns the normalized result to that outlet and replaces its earlier viewer-owned presentation
 - **AND** established semantic result components retain presentation authority
+- **AND** transient source result chrome is dismissed after handoff
 
 #### Scenario: Non-object result uses the shell outlet
 
 - **WHEN** a scalar or collection result is unclaimed and the active page has no eligible result outlet
-- **THEN** default policy assigns it to the one declared shell outlet
+- **THEN** default policy assigns it to the one declared shell outlet and replaces its earlier viewer-owned presentation
 - **AND** duplicate or disconnected outlets fail closed rather than receiving an arbitrary result
+- **AND** transient source result chrome is dismissed after handoff
+
+#### Scenario: Later object result replaces an earlier unsupported result
+
+- **WHEN** a result has been presented in a viewer-owned shell or page outlet and a later unclaimed action returns a navigable object
+- **THEN** the obsolete result presentation is cleared before or as canonical navigation is committed
+- **AND** the new object route contains no heading, message, or dismissal control belonging to the earlier result
 
 #### Scenario: Void result retains its target
 
 - **WHEN** a successful void action leaves the current route object available
 - **THEN** default policy refreshes the current object context without adding a history entry
-- **AND** preserves accessible result status
+- **AND** replaces obsolete viewer-owned result presentation with accessible completion status
+- **AND** dismisses transient source result chrome
 
 #### Scenario: Void result removes its target
 
 - **WHEN** the authoritative post-action refresh establishes that the current route object no longer exists
-- **THEN** default policy replaces the route with configured home
-- **AND** does not leave a stale object page in history state
+- **THEN** default policy clears obsolete viewer-owned result presentation and replaces the route with configured home
+- **AND** does not leave a stale object page or result in history state
 
 #### Scenario: Application replaces policy
 
 - **WHEN** an application handler claims a navigation, home, or result event
 - **THEN** the handler receives the unchanged semantic payload
-- **AND** default policy does not also handle that event
+- **AND** default policy does not navigate, present, clear, or dismiss on the handler's behalf
 
 ### Requirement: Accessible generation-scoped route lifecycle
 
@@ -298,7 +310,8 @@ The reference application SHALL support wide and narrow layouts, light and dark
 ### Requirement: Executable Vue Petclinic acceptance application
 
 The project SHALL provide a production-built Vue Petclinic application that reuses the same deterministic Petclinic domain, public logical types, and fixture identities as the HTMX sample without copying domain implementation.
-The application SHALL demonstrate source-visible exact-type Vue pages, generic fallback, a stable application-owned shell, menus, interactions, results, canonical routing, and server refresh fallback.
+The application SHALL demonstrate source-visible exact-type Vue pages, generic fallback, a stable application-owned shell, one current-username utility menu, interactions, results, canonical routing, and server refresh fallback.
+The application SHALL use Account only as a non-identifying fallback when authoritative current-user display identity is unavailable and SHALL give exact Logout a distinct accessible outlined presentation.
 For the shell and the `petclinic.HomePage`, `petclinic.PetOwner`, `petclinic.Pet`, and `petclinic.Visit` routes, the HTMX Petclinic application SHALL be the authoritative presentation reference.
 Presentation equivalence SHALL preserve user-visible information architecture and responsive relationships without requiring framework wrapper markup or browser pixels to be identical.
 
@@ -319,7 +332,11 @@ Presentation equivalence SHALL preserve user-visible information architecture an
 #### Scenario: Vue shell is presented at a wide viewport
 
 - **WHEN** a reconciled route is ready at the documented wide acceptance viewport
-- **THEN** branding, primary menu order, utility-menu grouping, header geometry, content inset, typography, palette, footer content, and document-title suffix are equivalent to the HTMX shell
+- **THEN** branding, primary menu order, one tertiary utility menu, header geometry, content inset, typography, palette, footer content, and document-title suffix are equivalent to the HTMX shell
+- **AND** the utility menu title is the current username supplied by authoritative host context, or Account when no trustworthy display identity is available
+- **AND** no separate System or Account menu duplicates **Me** or remains empty
+- **AND** exact Logout is labelled **Sign out** and has a distinct accessible outlined or equivalently bounded treatment under native and Vaadin-backed presentation
+- **AND** adjacent actions do not inherit the sign-out treatment
 - **AND** the route uses the available width and reference column relationships without an accidental persistent container outline
 - **AND** keyboard users retain a visible focus indication on an appropriate heading or route landmark
 
@@ -336,6 +353,12 @@ Presentation equivalence SHALL preserve user-visible information architecture an
 - **AND** direct refresh and browser history retain that route
 - **AND** none of the four reconciled Petclinic route types is used to demonstrate fallback
 
+#### Scenario: Tertiary object actions navigate without stale results
+
+- **WHEN** browser acceptance activates **Me** and then **Configuration** through the username-labelled utility menu
+- **THEN** each complete object result navigates to its canonical generic Vue object route
+- **AND** the second route retains no source panel or host result belonging to the first action
+
 #### Scenario: Existing HTMX Petclinic is rebuilt
 
 - **WHEN** Vue presentation is reconciled with the HTMX reference
@@ -352,7 +375,7 @@ Presentation equivalence SHALL preserve user-visible information architecture an
 #### Scenario: Acceptance suite runs
 
 - **WHEN** the Vue browser profile executes
-- **THEN** it covers direct links, refresh, back and forward, exact custom-page precedence, deliberate generic fallback, menus, property and action interactions, object and collection results, partial errors, invalid routes, absent objects, responsive layout, keyboard focus, announcements, and both supported component toolkit policies
+- **THEN** it covers direct links, refresh, back and forward, exact custom-page precedence, deliberate generic fallback, username-labelled utility menus, distinct exact-Logout presentation, tertiary object-result lifecycle, property and action interactions, object and collection results, partial errors, invalid routes, absent objects, responsive layout, keyboard focus, announcements, and both supported component toolkit policies
 - **AND** browser console errors, page errors, failed resource requests, and accessibility violations fail the suite
 
 ### Requirement: Reactor and release integration
diff --git a/openspec/specs/htmx-viewer-local-secman-authentication/spec.md b/openspec/specs/htmx-viewer-local-secman-authentication/spec.md
index ed291d7f658..7b47dc0b2e3 100644
--- a/openspec/specs/htmx-viewer-local-secman-authentication/spec.md
+++ b/openspec/specs/htmx-viewer-local-secman-authentication/spec.md
@@ -244,7 +244,7 @@ The host MUST use its native current-CSRF POST logout contract for activation an
 
 The project SHALL provide a deterministic secured Petclinic application configuration and acceptance suite that exercises the local authentication capability without requiring Wicket, bypass security, OAuth, or a live identity provider.
 The deterministic secured user SHALL receive the established regular-user and configuration-access roles in addition to the Petclinic application role, so authorized framework tertiary actions remain available.
-The existing Petclinic default runtime and comparison journey MUST remain available unchanged by default.
+The existing Petclinic default runtime and comparison journey MUST remain available, with changes limited to the intended consolidated utility-menu presentation.
 
 #### Scenario: Secured runtime starts
 
@@ -255,20 +255,23 @@ The existing Petclinic default runtime and comparison journey MUST remain availa
 #### Scenario: Authorized tertiary actions are preserved
 
 - **WHEN** the deterministic secured user loads the HTMX application menus
-- **THEN** exact framework **Me**, **Configuration**, and Logout actions are present in their authoritative tertiary menu locations
-- **AND** Logout is presented as **Sign out** while **Me** and **Configuration** retain their authoritative labels and identities
-- **AND** the viewer does not synthesize an action that SecMan omits
+- **THEN** exact framework **Me**, **Configuration**, and Logout actions are present in one authoritative tertiary utility menu labelled `sven`
+- **AND** Logout is presented as **Sign out** with a distinct accessible outlined or equivalently bounded treatment while **Me** and **Configuration** retain their authoritative labels, identities, and ordinary treatment
+- **AND** no separate System or Account menu duplicates **Me** or remains empty
+- **AND** the username label comes from authenticated host context and is not exposed before authentication
+- **AND** the viewer does not synthesize an action that SecMan omits or identify Logout from presentation text
 
 #### Scenario: Browser authentication journey runs
 
-- **WHEN** the browser suite exercises invalid login, valid login, a saved deep link, authorized reads and mutations, tertiary framework actions, logout, history, and session expiry
+- **WHEN** the browser suite exercises invalid login, valid login, a saved deep link, authorized reads and mutations, username-menu framework actions, logout, history, and session expiry
 - **THEN** each transition satisfies the local authentication, authorization, CSRF, routing, and confidentiality requirements
 - **AND** no unexpected browser, GraphQL, HTTP, persistence, or security failure is recorded
 
 #### Scenario: Ordinary Petclinic runtime starts
 
 - **WHEN** the existing default Petclinic application is launched without the optional authentication configuration
-- **THEN** its current HTMX, Wicket comparison, fixture, tertiary menu, and bypass behavior remains unchanged
+- **THEN** its current HTMX, Wicket comparison, fixture, and bypass behavior remain available
+- **AND** utility-menu differences are limited to consolidation, the authoritative username label when available, and exact-Logout presentation
 
 ### Requirement: HTMX authentication consumes the shared bridge
 
diff --git a/openspec/specs/vue-viewer-local-secman-authentication/spec.md b/openspec/specs/vue-viewer-local-secman-authentication/spec.md
index 97477b22105..c414d360212 100644
--- a/openspec/specs/vue-viewer-local-secman-authentication/spec.md
+++ b/openspec/specs/vue-viewer-local-secman-authentication/spec.md
@@ -187,7 +187,8 @@ It MUST NOT claim unrelated Wicket, HTMX, actuator, console, application, or bea
 ### Requirement: Secured Vue Petclinic acceptance runtime
 
 The Vue Petclinic sample SHALL provide a deterministic secured application variant using the same shared domain, production frontend assets, local user credentials, and profile context as secured HTMX.
-The deterministic secured user SHALL receive the established regular-user and configuration-access roles in addition to the Petclinic application role, so authorized framework tertiary actions remain available.
+The deterministic secured user SHALL receive the established regular-user and configuration-access roles in addition to the Petclinic application role, so authorized framework utility actions remain available in one tertiary menu labelled with the authenticated username.
+Exact Logout SHALL retain host-owned behavior while receiving a distinct accessible outlined presentation.
 It SHALL provide integration and headless browser coverage without requiring HTMX, Wicket, bypass security, OAuth, or a live identity provider.
 
 #### Scenario: Secured Vue runtime starts
@@ -196,15 +197,24 @@ It SHALL provide integration and headless browser coverage without requiring HTM
 - **THEN** anonymous Vue and GraphQL access is protected and login remains available without GraphQL
 - **AND** the ordinary Vue runtime remains available through its unchanged profile
 
-#### Scenario: Authorized tertiary actions are preserved
+#### Scenario: Authorized utility actions are preserved
 
 - **WHEN** the deterministic secured user loads the Vue application menus
-- **THEN** exact framework **Me**, **Configuration**, and Logout actions are present in their authoritative tertiary menu locations
-- **AND** Logout is presented as **Sign out** while **Me** and **Configuration** retain their authoritative labels and identities
-- **AND** the viewer does not synthesize an action that SecMan omits
+- **THEN** exact framework **Me**, **Configuration**, and Logout actions are present in one authoritative tertiary utility menu labelled `sven`
+- **AND** Logout is presented as **Sign out** with a distinct accessible outlined or equivalently bounded treatment while **Me** and **Configuration** retain their authoritative labels, identities, and ordinary treatment
+- **AND** no separate System or Account menu duplicates **Me** or remains empty
+- **AND** the username label comes from authenticated host context and is not exposed before authentication
+- **AND** the viewer does not synthesize an action that SecMan omits or identify Logout from presentation text
+
+#### Scenario: Secured utility-menu object actions navigate cleanly
+
+- **WHEN** the authenticated user activates **Me** and then **Configuration** from the username-labelled utility menu
+- **THEN** Vue navigates each complete object result to its canonical object route
+- **AND** `UserMemento` is presented through ordinary generic object rendering without a type-specific page
+- **AND** neither transient source result chrome nor presentation belonging to the previous action remains visible
 
 #### Scenario: Secured browser journey runs
 
-- **WHEN** headless automation exercises invalid and valid login, deep-link restoration, authorized reads and mutations, tertiary framework actions, CSRF rejection, host logout, history, and session expiry
-- **THEN** each transition satisfies the authentication, authorization, routing, CSRF, and confidentiality contracts
+- **WHEN** headless automation exercises invalid and valid login, deep-link restoration, authorized reads and mutations, username-menu framework actions, CSRF rejection, host logout, history, and session expiry
+- **THEN** each transition satisfies the authentication, authorization, routing, result-lifecycle, CSRF, and confidentiality contracts
 - **AND** unexpected browser, GraphQL, HTTP, persistence, or security failures fail the suite