Public Access
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# 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.
|