Merge latest main into macOS support and preserve portable integrations

docs/meeting-workflow-engine.md

@@ -28,6 +28,12 @@ The tray menu includes `Open agent`, which opens the `Meeting Summary Agent` cha
 
 Meeting Assistant detects the host operating system once during application startup and appends that context to the interactive agent prompt. Windows hosts receive PowerShell, Windows-path, Windows-service, and Task Manager guidance. macOS hosts receive zsh, POSIX-path, launchd/LaunchAgent, and Activity Monitor guidance. Other hosts receive neutral portable guidance. The platform context remains present when `WorkflowRulesEditor:InitialPrompt` is configured, and it does not imply that unavailable platform integrations have been implemented.
 
+The automatic summarizer can propose changes through `request_workflow_change(intention, detailed_prompt)` but has no direct workflow write tool. `intention` is one nonempty line of at most 100 characters; `detailed_prompt` contains the complete desired change, preferably as a scenario/specification. A Windows notification displays `Workflow change requested: ...` with Yes/No actions. The tool returns requested immediately so summarization continues. Yes opens a separate settings-agent window and automatically submits the complete detailed prompt; existing conversations and drafts are left intact. No or ten minutes without approval discards the request and removes the notification. Workflow requests can be approved after their summary finishes but are not persisted across application restarts. The settings agent applies approved requests through its normal validated tools.
+
+Project association requests follow a separate blocking path. `request_project_association` waits up to ten minutes before the summarizer continues; approval appends the project ID to meeting frontmatter and returns its instructions. This does not emit a new workflow trigger or change the YAML rule schema. See the configuration guide for project catalog metadata and access rules.
+
+Automatic approval notifications are currently Windows-only. On macOS and other portable hosts, workflow-change and project-association requests are declined without opening an agent conversation or applying the requested change. The existing interactive macOS agent remains available from the menu bar.
+
 ```json
 {
   "MeetingAssistant": {
@@ -97,6 +103,8 @@ For every event, the engine:
 
 For `transcript_line` events, the engine returns the possibly updated transcript line to the caller. Live transcript appends first write the original formatted line and keep a reference to that exact body line, then run transcript-line rules out of band. Later transcript segments can continue to be appended while the workflow runs. If rules return a changed line, Meeting Assistant rewrites the referenced line in the transcript file. If a transcript-line rule fails during live recording, Meeting Assistant logs the failure and keeps the original line so later transcript segments can continue to be written.
 
+Offline transcription recovery applies `transcript_line` transformations to the recovered lines before appending them to the existing transcript. Earlier transcript content is preserved and is not transformed again. Each appended recovery section starts with a visible marker explaining that replaying the entire recording may produce duplicate passages, which the summary agent should treat as the same discussion. The marker bypasses transcript-line rules so the recovery explanation remains intact. A replay without non-blank speech text skips workflow events, transcript writes, and summarization, and retains its backlog item and WAV for another retry.
+
 Rules are best-effort automation for live transcript persistence. The settings/logs write tool rejects invalid YAML, unknown steps, unsupported set-property fields, trigger or condition entries without a supported key, and step value Razor templates that fail against the workflow template model before writing the rules file. Invalid NCalc expressions can still fail at workflow runtime. Workflow execution logs every triggered rule with its rule name and event type, logs completion with whether the note or transcript line changed, and logs rule failures with the rule name and event type.
 
 ## YAML Shape