fix shared release version prefix

Author: KSemenenko

.github/workflows/release-publish.yml

@@ -61,9 +61,9 @@ jobs:
         id: resolve_version
         shell: bash
         run: |
-          version_prefix="$(dotnet msbuild ./DotPilot/DotPilot.csproj -getProperty:ApplicationDisplayVersion | tail -n 1 | tr -d '\r')"
+          version_prefix="$(dotnet msbuild ./DotPilot/DotPilot.csproj -getProperty:DotPilotVersionPrefix | tail -n 1 | tr -d '\r')"
           if [[ ! "${version_prefix}" =~ ^[0-9]+\.[0-9]+$ ]]; then
-            echo "ApplicationDisplayVersion must be a two-segment numeric prefix. Found: '${version_prefix}'." >&2
+            echo "DotPilotVersionPrefix must be a two-segment numeric prefix. Found: '${version_prefix}'." >&2
             exit 1
           fi
 
@@ -129,8 +129,8 @@ jobs:
             -p:PackageFormat=dmg \
             -p:CodesignKey=- \
             -p:DiskImageSigningKey=- \
-            -p:ApplicationDisplayVersion=${{ needs.prepare_release.outputs.release_version }} \
-            -p:ApplicationVersion=${{ needs.prepare_release.outputs.application_version }}
+            -p:DotPilotReleaseVersion=${{ needs.prepare_release.outputs.release_version }} \
+            -p:DotPilotBuildNumber=${{ needs.prepare_release.outputs.application_version }}
 
       - name: Stage macOS Release Asset
         shell: bash
@@ -186,8 +186,8 @@ jobs:
           -p:PublishSingleFile=true
           -p:IncludeNativeLibrariesForSelfExtract=true
           -p:IncludeAllContentForSelfExtract=true
-          -p:ApplicationDisplayVersion=${{ needs.prepare_release.outputs.release_version }}
-          -p:ApplicationVersion=${{ needs.prepare_release.outputs.application_version }}
+          -p:DotPilotReleaseVersion=${{ needs.prepare_release.outputs.release_version }}
+          -p:DotPilotBuildNumber=${{ needs.prepare_release.outputs.application_version }}
 
       - name: Stage Windows Release Asset
         shell: pwsh
@@ -254,8 +254,8 @@ jobs:
             -p:SelfContained=true \
             -p:PackageFormat=snap \
             -p:UnoSnapcraftAdditionalParameters=--destructive-mode \
-            -p:ApplicationDisplayVersion=${{ needs.prepare_release.outputs.release_version }} \
-            -p:ApplicationVersion=${{ needs.prepare_release.outputs.application_version }}
+            -p:DotPilotReleaseVersion=${{ needs.prepare_release.outputs.release_version }} \
+            -p:DotPilotBuildNumber=${{ needs.prepare_release.outputs.application_version }}
 
           sudo chown -R "$USER:$USER" ./bin/Release/net10.0-desktop/linux-x64
 

AGENTS.md

@@ -212,9 +212,12 @@ For this app:
 - after changing GitHub rulesets, workflows, or release packaging, verify against the specific live blocked operation or failing run instead of assuming the policy or YAML change solved the issue
 - desktop app build or publish jobs must use native runners for their target OS: macOS artifacts on macOS runners, Windows artifacts on Windows runners, and Linux artifacts on Linux runners
 - desktop release assets must be native installable or directly executable outputs for each OS, not archives of raw publish folders; package the real `.exe`, `.snap`, `.dmg`, `.pkg`, `Setup.exe`, or equivalent runnable installer/app artifact instead of zipping intermediate publish directories
-- desktop release versions must use the `ApplicationDisplayVersion` value in `DotPilot/DotPilot.csproj` as a manually maintained two-segment prefix, with CI appending the final segment from the build number (for example `0.0.<build-number>`)
-- until the user explicitly changes the versioning policy, the manually maintained `ApplicationDisplayVersion` prefix for desktop releases must stay `0.0`, not `1.0`
-- the release workflow must not take ownership of the first two version segments; those remain manually edited in source, while CI supplies only the last numeric segment and matching release tag/application version values
+- desktop release version-prefix source of truth must live in `Directory.Build.props`, not as a separately maintained value in `DotPilot/DotPilot.csproj`
+- until the user explicitly changes the versioning policy, the shared desktop release version prefix must stay `0.0`
+- the release workflow must not take ownership of the human-managed prefix; CI may append only the final build segment to produce release versions such as `0.0.<build-number>`
+- keep `ApplicationDisplayVersion` aligned to the shared version prefix during normal project evaluation, and let CI override it only with the final three-segment release version
+- do not maintain a separate human-edited `ApplicationVersion` prefix in app projects; when packaging needs a build value, derive it from CI/build metadata instead of duplicating version authority
+- the production desktop app identifier must be `com.managed-code.dotpilot`
 - for CI and release automation in this solution, prefer existing `dotnet` and `MSBuild` capabilities plus small workflow-native steps over Python or adding a separate helper project for simple versioning and release-note tasks
 - prefer MIT-licensed GitHub and NuGet dependencies when they materially accelerate delivery and align with the current architecture
 - prefer official `.NET` AI evaluation libraries under `Microsoft.Extensions.AI.Evaluation*` for response-quality, tool-usage, and safety evaluation instead of custom or third-party evaluation stacks by default

Directory.Build.props

@@ -4,6 +4,9 @@
     <ImplicitUsings>enable</ImplicitUsings>
     <LangVersion>14</LangVersion>
 
+    <DotPilotVersionPrefix Condition="'$(DotPilotVersionPrefix)' == ''">0.0</DotPilotVersionPrefix>
+    <DotPilotBuildNumber Condition="'$(DotPilotBuildNumber)' == ''">1</DotPilotBuildNumber>
+    <DotPilotReleaseVersion Condition="'$(DotPilotReleaseVersion)' == ''">$(DotPilotVersionPrefix)</DotPilotReleaseVersion>
 
     <EnableNETAnalyzers>true</EnableNETAnalyzers>
     <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>

DotPilot/DotPilot.csproj

@@ -10,10 +10,10 @@
         <!-- Display name -->
         <ApplicationTitle>DotPilot</ApplicationTitle>
         <!-- App Identifier -->
-        <ApplicationId>com.companyname.DotPilot</ApplicationId>
+        <ApplicationId>com.managed-code.dotpilot</ApplicationId>
         <!-- Versions -->
-        <ApplicationDisplayVersion>0.0</ApplicationDisplayVersion>
-        <ApplicationVersion>1</ApplicationVersion>
+        <ApplicationDisplayVersion>$(DotPilotReleaseVersion)</ApplicationDisplayVersion>
+        <ApplicationVersion>$(DotPilotBuildNumber)</ApplicationVersion>
         <!-- Package Publisher -->
         <ApplicationPublisher>O=DotPilot</ApplicationPublisher>
         <!-- Package Description -->

docs/ADR/ADR-0002-split-github-actions-build-and-release.md

@@ -16,7 +16,7 @@ That shape no longer matches the repository workflow:
 
 - normal validation should stay focused on build and test feedback
 - release publishing has different permissions, side effects, and operator intent
-- the release path now needs CI-derived version resolution from `DotPilot/DotPilot.csproj`
+- the release path now needs CI-derived version resolution from the shared version prefix in `Directory.Build.props`
 - desktop releases must publish platform artifacts and create a GitHub Release with feature-oriented notes
 
 Keeping all of that in one catch-all workflow makes the automation harder to reason about, harder to secure, and harder to operate safely.
@@ -31,7 +31,7 @@ We will split GitHub Actions into two explicit workflows:
    - does not publish desktop artifacts or create releases
 2. `release-publish.yml`
    - runs automatically on pushes to `main`
-   - resolves the release version from the two-segment `ApplicationDisplayVersion` prefix in `DotPilot/DotPilot.csproj` plus the GitHub Actions build number
+   - resolves the release version from the two-segment `DotPilotVersionPrefix` value in `Directory.Build.props` plus the GitHub Actions build number
    - publishes desktop release assets for macOS, Windows, and Linux as real packaged outputs instead of raw publish-folder archives
    - uses `.dmg` for macOS, a self-contained single-file `.exe` for Windows, and `.snap` for Linux
    - creates the GitHub Release
@@ -73,7 +73,7 @@ This keeps unrelated concerns coupled and makes ordinary CI runs carry release-s
 
 Rejected.
 
-The repository still needs a manual source-of-truth prefix in `DotPilot/DotPilot.csproj`, but the final build segment should be CI-derived so every `main` release is unique without generating a release-only source commit.
+The repository still needs a manual source-of-truth prefix in `Directory.Build.props`, but the final build segment should be CI-derived so every `main` release is unique without generating a release-only source commit.
 
 ### 3. Store release notes entirely as manual workflow input
 
@@ -94,7 +94,7 @@ That makes release quality depend on operator memory instead of repo-owned histo
 ### Negative
 
 - Release automation now depends on the GitHub Actions run number remaining a suitable build-number source for releases.
-- The repository gains workflow-owned release logic that must stay aligned with `DotPilot.csproj`, git history, and `docs/Features/`.
+- The repository gains workflow-owned release logic that must stay aligned with `Directory.Build.props`, project packaging metadata, git history, and `docs/Features/`.
 
 ## Implementation Impact