Add meeting workflow automation

2026-05-27 12:55:18 +02:00
parent e85274829a
commit b114071957
29 changed files with 1703 additions and 12 deletions
@@ -0,0 +1,15 @@
+# Change: Add meeting automation rules
+
+## Why
+Manual meeting-specific adjustments such as adding default attendees, cleaning titles, binding projects, or adding context notes should be configurable without recompiling Meeting Assistant.
+
+## What Changes
+- Add a configurable local YAML rules file.
+- Evaluate rules on meeting lifecycle events.
+- Support a small workflow surface: triggers, conditions, and meeting/context mutation steps.
+- Use a real expression engine for conditions and Razor syntax for step values.
+
+## Impact
+- Adds a local-only rules file path setting.
+- Adds meeting automation runtime code and tests.
+- Keeps the initial step surface intentionally small.
@@ -0,0 +1,69 @@
+## ADDED Requirements
+### Requirement: Meeting automation rules are configurable
+Meeting Assistant SHALL allow an optional local YAML rules file path to be configured.
+
+When the configured rules file is missing or blank, Meeting Assistant SHALL continue without applying automation rules.
+
+The local rules file SHALL be ignored by source control.
+
+Rules SHALL be evaluated against the latest meeting note data read from disk for each event.
+
+#### Scenario: Missing rules file is ignored
+- **WHEN** Meeting Assistant handles a meeting event and no configured rules file exists
+- **THEN** it leaves the meeting note and assistant context unchanged
+
+#### Scenario: Created rule adds default attendee
+- **GIVEN** a configured rule that triggers on meeting creation when `meeting.attendees.count = 0`
+- **WHEN** Meeting Assistant creates a meeting note without attendees
+- **THEN** it adds the configured attendee to the meeting note
+
+### Requirement: Meeting automation rules support lifecycle triggers
+Meeting Assistant SHALL support rule triggers for `created`, `state_transition`, and `speaker_identified`.
+
+A `state_transition` trigger MAY filter by `from`, `to`, or both state values.
+
+A `speaker_identified` trigger MAY filter by speaker name.
+
+#### Scenario: State transition rule matches from and to
+- **GIVEN** a configured rule that triggers on a state transition from `collecting metadata` to `transcribing`
+- **WHEN** Meeting Assistant transitions that meeting from `collecting metadata` to `transcribing`
+- **THEN** it applies the rule steps
+
+#### Scenario: Speaker identified rule filters by name
+- **GIVEN** a configured rule that triggers when speaker `Ada` is identified
+- **WHEN** Meeting Assistant identifies speaker `Grace`
+- **THEN** it does not apply the rule
+- **WHEN** Meeting Assistant identifies speaker `Ada`
+- **THEN** it applies the rule steps
+
+### Requirement: Meeting automation rules support conditions and steps
+Meeting Assistant SHALL support rule conditions using an expression engine.
+
+Rules SHALL support nested `and`, `or`, and `not` condition groups.
+
+Step values SHALL support Razor syntax against the current meeting event model.
+
+Meeting Assistant SHALL support these initial rule steps:
+
+- `add_attendee`
+- `remove_attendee`
+- `set_property`
+- `add_context`
+- `add_project`
+
+#### Scenario: Nested conditions choose a matching rule
+- **GIVEN** a configured rule with nested `and`, `or`, and `not` conditions over meeting title, attendees, and event data
+- **WHEN** the condition evaluates to true
+- **THEN** Meeting Assistant applies the rule
+- **WHEN** the condition evaluates to false
+- **THEN** Meeting Assistant skips the rule
+
+#### Scenario: Templated context mentions identified speaker
+- **GIVEN** a configured `speaker_identified` rule with an `add_context` step using Razor syntax
+- **WHEN** Meeting Assistant identifies matching speaker `Ada`
+- **THEN** it appends rendered context text containing `Ada` to the assistant context note
+
+#### Scenario: Rule can clean a meeting title
+- **GIVEN** a configured state-transition rule that matches a title containing a configured marker
+- **WHEN** the rule runs
+- **THEN** Meeting Assistant can update the meeting title through `set_property`
@@ -0,0 +1,12 @@
+## 1. Implementation
+- [x] 1.1 Add automation options and ignore the local rules YAML file.
+- [x] 1.2 Load YAML rules from the configured local file.
+- [x] 1.3 Evaluate triggers and nested conditions.
+- [x] 1.4 Render step values with Razor syntax.
+- [x] 1.5 Apply supported steps to meeting notes and assistant context.
+- [x] 1.6 Fire rules from meeting creation, state transitions, and speaker identification.
+
+## 2. Verification
+- [x] 2.1 Cover created, state-transition, and speaker-identified paths.
+- [x] 2.2 Cover nested condition logic and templated values.
+- [x] 2.3 Run relevant tests and strict OpenSpec validation.
@@ -0,0 +1,12 @@
+# Change: Copy attendees to summary frontmatter
+
+## Why
+The summary note should retain the final attendee list from the meeting note so the generated summary artifact can be filtered and reviewed without opening the meeting note.
+
+## What Changes
+- When the summary agent writes a summary note, copy attendees from the current meeting note into summary frontmatter.
+- If the summary note already has an `attendees` frontmatter property, preserve that existing value.
+
+## Impact
+- Updates summary artifact frontmatter rendering.
+- Adds focused summary tool tests.
@@ -0,0 +1,14 @@
+## MODIFIED Requirements
+### Requirement: Meeting Assistant generates meeting outputs
+The summary note SHALL keep frontmatter links to meeting artifacts and SHALL copy `title`, `start_time`, `end_time`, and `attendees` from the meeting note when available. If the meeting note has no title, the summary agent SHALL be able to provide a title when writing the summary.
+
+When the summary note already has an `attendees` frontmatter property, Meeting Assistant SHALL preserve the existing summary attendees instead of overwriting them from the meeting note.
+
+#### Scenario: Summary copies final meeting attendees
+- **WHEN** the summary agent writes a summary note after meeting attendees have changed
+- **THEN** the summary note frontmatter includes the final meeting note attendees
+
+#### Scenario: Existing summary attendees are preserved
+- **GIVEN** an existing summary note has `attendees` in frontmatter
+- **WHEN** the summary agent rewrites the summary
+- **THEN** Meeting Assistant preserves the existing summary attendees
@@ -0,0 +1,8 @@
+## 1. Implementation
+- [x] 1.1 Render optional attendees in artifact frontmatter.
+- [x] 1.2 Copy meeting-note attendees when writing a new summary.
+- [x] 1.3 Preserve existing summary attendees when rewriting a summary.
+
+## 2. Verification
+- [x] 2.1 Add behavior tests for copied and preserved attendees.
+- [x] 2.2 Run focused tests and strict OpenSpec validation.
@@ -0,0 +1,9 @@
+# Change: Deduplicate attendee aliases after speaker identification
+
+## Why
+Speaker identification can confirm that multiple meeting-note attendee entries refer to the same person. When the attendee list contains both the identified speaker display name and one or more accepted aliases, later processing sees an inflated attendee count and noisier metadata.
+
+## What Changes
+- When a speaker is identified, remove attendee entries that match the identified speaker's aliases if the identified speaker display name is also present.
+- Preserve the existing alias-only behavior: an attendee alias by itself still prevents adding another canonical attendee entry.
+
@@ -0,0 +1,39 @@
+## MODIFIED Requirements
+### Requirement: Speaker identity matches relabel transcripts
+Meeting Assistant SHALL attempt to match unknown diarized speaker snippets against known speaker identities ordered by calculated meeting reference count.
+
+Speaker identity matching SHALL use a dedicated Azure Speech diarization verifier component rather than the configured speech recognition pipeline.
+
+The matcher SHALL test at most the configured batch size of known people per diarization session and continue with later batches until a match is found or no candidates remain.
+
+The matcher SHALL prioritize identities whose canonical name or aliases match current meeting attendees.
+
+After attendee-matched identities, the matcher SHALL order identities by calculated meeting reference count, filter out non-attendee identities whose last update is older than the configured active age, and cap the candidate set at the configured maximum match candidate count.
+
+When a match is confirmed in final identity processing, Meeting Assistant SHALL store a meeting file reference for that identity.
+
+When a match is confirmed and the identity has a canonical name, Meeting Assistant SHALL rewrite finished transcript segments for that diarized speaker with the canonical name.
+
+When a match is confirmed and the matched speaker is not already listed in meeting note attendees by display name or alias, Meeting Assistant SHALL add the speaker display name to the attendee list.
+
+When a match is confirmed and the meeting note attendees contain both the speaker display name and one or more accepted aliases for that same speaker, Meeting Assistant SHALL remove the alias attendee entries and keep the display name entry.
+
+When Meeting Assistant writes attendees from calendar metadata, it SHALL match attendee display names exactly against known identity canonical names and aliases, replace matches with the identity display name, and deduplicate attendees that map to the same identity.
+
+#### Scenario: Finished transcript is relabeled after a confirmed match
+- **GIVEN** the speaker identity database contains canonical speaker `Chris`
+- **WHEN** a finished transcript has diarized speaker `Guest03` and the matching backend confirms it is `Chris`
+- **THEN** Meeting Assistant rewrites `Guest03` segments in the transcript as `Chris`
+
+#### Scenario: Confirmed match stores meeting reference
+- **GIVEN** the speaker identity database contains canonical speaker `Chris`
+- **WHEN** a finished transcript has diarized speaker `Guest03` and the matching backend confirms it is `Chris`
+- **THEN** Meeting Assistant stores the meeting note and transcript file addresses as a reference for `Chris`
+
+#### Scenario: Confirmed match removes duplicate aliases
+- **GIVEN** the speaker identity database contains canonical speaker `Christopher` with alias `Chris`
+- **AND** the meeting note attendees contain both `Christopher` and `Chris <chris@example.com>`
+- **WHEN** live or final speaker matching confirms a diarized speaker is `Christopher`
+- **THEN** Meeting Assistant keeps `Christopher` in the meeting note attendees
+- **AND** removes `Chris <chris@example.com>` from the meeting note attendees
+
@@ -0,0 +1,7 @@
+## 1. Implementation
+- [x] 1.1 Add a behavior test for removing alias duplicates when canonical attendee is present.
+- [x] 1.2 Remove duplicate alias attendee entries during speaker identification.
+
+## 2. Verification
+- [x] 2.1 Run focused recording coordinator tests.
+- [x] 2.2 Run strict OpenSpec validation.