Add attendee transformation workflows

This commit is contained in:
2026-07-01 11:10:36 +02:00
parent 92e359646b
commit 5c67738939
23 changed files with 694 additions and 123 deletions
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-07-01
@@ -0,0 +1,30 @@
# Design
## Event Model
Add a workflow event type, `attendee_added`, that carries the attendee string being added. The event is used as a transformation hook before a caller stores the attendee in the meeting note. Rules can match the event with `equals`, `contains`, or `regex` trigger filters over the current attendee value.
## Transformation Contract
The workflow engine exposes `TransformAttendeeAsync`, mirroring `TransformTranscriptLineAsync`. During `attendee_added` events:
- conditions can read `attendee.name`,
- Razor templates can read `Model.Attendee.Name`,
- `set_property attendee.name` mutates the attendee value returned to the caller.
Other workflow steps keep their existing semantics, but the intended transformation path is `set_property attendee.name`.
Rules triggered by `attendee_added` are limited to that transformation path so the value transform does not hide unrelated note or context side effects.
Direct meeting note file edits remain outside the workflow event model. If a user or agent writes a meeting note file/frontmatter directly, Meeting Assistant preserves that content verbatim and does not emit `attendee_added`.
## Call Sites
Callers transform attendee candidates before writing them:
- metadata and accepted prompt metadata after canonicalization,
- workflow `add_attendee` steps before de-duplication,
- screenshot OCR candidates before canonicalization and merge,
- summary-agent `add_attendee` tool calls before duplicate checks and note writes,
- speaker identity attendee additions before adding matched names.
Unchanged metadata attendees preserve the existing canonicalizer output, including email display strings.
@@ -0,0 +1,17 @@
## Why
Attendees enter Meeting Assistant from several paths: calendar metadata, accepted recording prompts, workflow actions, screenshot OCR, speaker identity updates, and summarizer add-attendee tools. Today those paths can normalize display names, but they cannot apply local transformation rules such as trimming company suffixes, replacing aliases, or cleaning attendee strings consistently.
## What Changes
- Add an `attendee_added` workflow trigger that runs whenever Meeting Assistant adds an attendee to a meeting note.
- Allow `attendee_added` triggers to filter the added attendee with full equality, substring, or regex matching.
- Expose `attendee.name` to workflow conditions and Razor templates.
- Allow `set_property` to update `attendee.name` during `attendee_added` events, mirroring transcript-line transformation.
- Apply attendee transformations to attendees added by metadata import, prompted-start metadata, workflow `add_attendee`, screenshot OCR, and summary/workflow editor agent tools.
## Impact
- Workflow engine, rules schema validation, and workflow documentation.
- Attendee write paths in recording metadata, screenshot OCR, summary tools, and workflow actions.
- Behavior tests for workflow transformation and representative attendee-add sources.
@@ -0,0 +1,29 @@
## MODIFIED Requirements
### Requirement: Meeting automation rules support lifecycle triggers
Meeting Assistant SHALL support rule triggers for `created`, `state_transition`, `speaker_identified`, `transcript_line`, and `attendee_added`.
An `attendee_added` trigger MAY filter by `equals`, `contains`, or `regex` against the attendee value being added. `equals` and `contains` filters SHALL match case-insensitively.
Meeting Assistant SHALL apply attendee-added transformations before storing attendees added from meeting metadata, accepted recording-prompt metadata, workflow `add_attendee` steps, screenshot OCR, speaker identity updates, and summarizer add-attendee tools.
#### Scenario: Attendee added rule filters and transforms a metadata attendee
- **GIVEN** a configured rule that triggers on added attendees containing `@contoso.com`
- **AND** the rule sets `attendee.name` to a display name derived from the added attendee
- **WHEN** Meeting Assistant adds attendee `Ada Lovelace <ada@contoso.com>` from meeting metadata
- **THEN** the stored meeting attendee is the transformed attendee name
- **AND** the original attendee string is not stored
### Requirement: Meeting automation rules support conditions and steps
Meeting Assistant SHALL expose the added attendee name to `attendee_added` rule conditions and Razor step templates as `attendee.name`.
The `set_property` step SHALL support setting `attendee.name` during `attendee_added` events.
Rules with an `attendee_added` trigger SHALL be limited to transforming `attendee.name` with `set_property`.
Direct meeting note file writes SHALL NOT emit `attendee_added` or transform attendee values.
#### Scenario: Attendee added rules can use regex and Razor
- **GIVEN** a configured `attendee_added` rule with a regex filter over the added attendee
- **WHEN** Meeting Assistant adds an attendee matching the regex
- **THEN** the rule can set `attendee.name` with a Razor template using `Model.Attendee.Name`
@@ -0,0 +1,8 @@
# Tasks
- [x] Add OpenSpec scenarios for attendee-added trigger filtering and transformation.
- [x] Add a failing workflow-engine behavior test for transforming an added attendee through `attendee_added`.
- [x] Implement attendee-added workflow event, trigger filters, `attendee.name` condition/template value, and `set_property attendee.name`.
- [x] Apply attendee transformations from metadata/prompted starts, workflow `add_attendee`, screenshot OCR, and agent attendee tools.
- [x] Update workflow engine documentation.
- [x] Run focused tests plus `openspec validate transform-added-attendees --strict`.