Changed how pull requests bring their changes into the wiki (#1140)

.github/pull_request_template.md

@@ -21,6 +21,10 @@ once it is done: that is our signal to take over. The automated check waits unti
 
 <!-- For example: ran `dotnet run verify`, ran the app locally, and tried out … -->
 
+## Wiki
+
+<!-- Does this change something users or IT departments notice, such as a new feature, a changed default, or a new setting for configuration plugins? Then describe what the wiki should say about it; the maintainers update the wiki when the release comes out. Otherwise, write "none". -->
+
 ## Required statements
 
 <!-- Please tick each box yourself: these are statements you make personally, see "Licensing of your contribution" in CONTRIBUTING.md. Do not change their wording; the automated check compares it word by word. -->

AGENTS.md

@@ -205,21 +205,16 @@ The documentation for users and IT departments lives in the wiki, https://github
 the user guide in US English and German, the Enterprise IT guides, and pages for developers. The files in
 `documentation/` are meant for contributors.
 
-- The wiki is a Git repository of its own, `MindWorkAI/AI-Studio.wiki`, with the folders `user-guide/` and
-  `de/` for the user guide, `enterprise/`, and `developers/`. GitHub renders only its `master` branch, and
-  only collaborators of the repository can change it.
+The maintainers write the wiki, and they update it when a release is published, not before: a page which
+describes a version nobody can install yet misleads users and IT departments. Contributors need neither
+access to the wiki nor a copy of it.
+
 - A change which users or IT departments notice, such as a new assistant, a changed default, or a new
-  capability of configuration plugins, needs its wiki pages updated no later than the release which ships
-  it. When the wiki is cloned next to this repository, as `../AI-Studio.wiki`, change it there in commits of
-  its own. Otherwise, name the needed changes in the description of the pull request.
-- Mark what needs a certain version with "Requires AI Studio vX.Y.Z or newer": organizations take weeks
-  until every device runs a new version, so the pages describe several versions at once.
-- Write each page of the user guide in both languages, in the same commit; its first line links to the
-  other language. German pages use the wording of the de-de language plugin and the formal "Sie", like the
-  app.
-- GitHub shows the file name of a page as its title. Start a page without a `#` heading, keep commas out of
-  file names, and keep each name unique across all folders, because the URLs ignore them. Link pages as
-  `[[Text|Page-Name]]`, and list a new page in the `_Sidebar.md` of its folder; `de/` has its own.
+  capability of configuration plugins, gets the section "Wiki" in the description of its pull request:
+  what changes for users or IT departments, which settings or configuration keys are new or changed, and
+  which pages of the wiki it concerns, if you know them. Write "none" when nobody notices the change.
+- Leave the wiki itself to the maintainers. They carry these sections into it for the release, see
+  "Release Process" in `app/Build/AGENTS.md`.
 
 ## Changelogs
 Changelogs are located in `app/MindWork AI Studio/wwwroot/changelog/` with filenames `vX.Y.Z.md`. These changelogs are meant to be for normal end-users

app/Build/AGENTS.md

@@ -17,9 +17,11 @@ changelog entries.
 6. After PR merge, maintainer creates git tag: `vX.Y.Z`
 7. GitHub Actions builds release binaries for all platforms
 8. Binaries uploaded to GitHub Releases
-9. Update the wiki (`MindWorkAI/AI-Studio.wiki`): raise the version in `_Footer.md` and `de/_Footer.md`, and
-   check that the user guide and the Enterprise IT pages describe the release; see "Wiki" in the root
-   `AGENTS.md`
+9. Once the release is published, update the wiki (`MindWorkAI/AI-Studio.wiki`): carry the "Wiki" sections
+   of the pull requests merged since the last release into it, mark what needs the new version with
+   "Requires AI Studio vX.Y.Z or newer", and raise the version in `_Footer.md` and `de/_Footer.md`. The
+   pull requests are listed by the command of step 2 with `--json number,title,body` and without `--jq`.
+   The release command reminds you of this step when it is done.
 
 ## Crediting contributors
 

app/Build/Commands/UpdateMetadataCommands.cs

@@ -46,6 +46,15 @@ public sealed partial class UpdateMetadataCommands
         await this.PerformPrepare(action, true, version);
 
         await this.BuildPreparedRelease(offline);
+
+        // The wiki is a repository of its own, and nothing in this build touches it.
+        // It describes what users can install, so it changes once the release is published:
+        Console.WriteLine();
+        Console.WriteLine("==============================");
+        Console.WriteLine("- Warning: Remember the wiki, https://github.com/MindWorkAI/AI-Studio/wiki");
+        Console.WriteLine("  Once the release is published, carry the \"Wiki\" sections of the pull requests merged since the");
+        Console.WriteLine("  last release into the wiki, and raise the version in _Footer.md and de/_Footer.md. See step 9 of");
+        Console.WriteLine("  \"Release Process\" in app/Build/AGENTS.md.");
     }
 
     [Command("rebuild-release", Description = "Prepare & build a new build of the current release")]

app/MindWork AI Studio/Tools/PluginSystem/AGENTS.md

@@ -40,7 +40,7 @@ When adding configuration plugin capabilities:
 - For managed settings, update the corresponding data class in `app/MindWork AI Studio/Settings/DataModel/` to call `ManagedConfiguration.Register(...)` and process the setting in `PluginConfiguration.TryProcessConfiguration`. Cleaning up the setting when its configuration plugin was removed needs no extra step: `ManagedConfiguration.CleanupLeftOverManagedConfigurations(...)` iterates all registered settings. Do not add per-setting cleanup calls to `PluginFactory.Loading.LoadAll`. `ManagedSettingsCoverageTests` fails for a registered setting which no configuration plugin can manage; a setting which must stay out of their reach goes into its list `EXEMPT_SETTINGS`, together with the reason.
 - For managed configuration objects, add the type to `PluginConfigurationObjectType.cs`, persist the objects in the appropriate `ConfigurationData` collection, and add a descriptor to `PluginConfigurationObjectDescriptors` and its list `ALL`: its Lua table, its parser, the collection, the next number, and where secrets are kept. Parsing and cleanup need no extra call; `PluginConfigurationObjectDescriptorsTests` fails for a type without a descriptor.
 - For live plugin content, add a data type implementing `ILivePluginContent`, parse it in `PluginConfiguration`, expose it through `PluginFactory`, and add any required cleanup only for persistent side data.
-- Always document the new capability in `app/MindWork AI Studio/Plugins/configuration/plugin.lua`, the reference of every setting, and explain it on the matching Enterprise IT page of the wiki, marked with the version which brings it; see "Wiki" in the root `AGENTS.md`.
+- Always document the new capability in `app/MindWork AI Studio/Plugins/configuration/plugin.lua`, the reference of every setting, and describe it for IT departments in the section "Wiki" of the pull request; see "Wiki" in the root `AGENTS.md`.
 
 ## Importing exported configuration objects