Public Access
Preserve recovery transcripts and add user-approved agent requests
PR and Push Build/Test / build-and-test (push) Successful in 12m0s
PR and Push Build/Test / build-and-test (push) Successful in 12m0s
Append successful offline recovery with a duplicate-warning marker and retain failed replay sources. Offer newly available microphones through confirmation notifications. Add project discovery metadata and blocking association approval, plus nonblocking workflow requests that start a separate settings-agent conversation. Include regression tests, OpenSpec changes, and verified local Release startup.
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-25
|
||||
@@ -0,0 +1,35 @@
|
||||
## Context
|
||||
|
||||
Project IDs are direct subfolder names. BoundMeetingProjectResolver reads the meeting note on each access. The summarizer already has project read/write tools and an initial section for bound AGENTS.md instructions, but writes currently accept any existing project. Native actionable toasts and a WPF settings-agent window already exist.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:** Discover projects using compact metadata, extend project access only after approval, maintain metadata through the agent, and forward approved workflow requests to the interactive settings agent.
|
||||
|
||||
**Non-Goals:** Bulk-generate metadata for unassociated projects, let the summarizer edit workflows directly, change project IDs, migrate UI frameworks, or deploy/restart the workstation service.
|
||||
|
||||
## Decisions
|
||||
|
||||
- Store `name` and `description` in the root `PROJECT.md` frontmatter; `name` is the display name, and the directory name remains the stable ID. Missing/invalid metadata falls back to the ID and an empty description. Catalog results contain metadata, never AGENTS.md or arbitrary project content.
|
||||
- Reuse write_projectfile for metadata maintenance. Validate resulting PROJECT.md frontmatter (name and description, maximum 256 description characters) before writing. Preserve ordinary file edit modes. Restrict writes to associated projects, matching existing read/search permissions.
|
||||
- Append metadata and AGENTS.md at the existing initial project section. Add mandatory capability guidance even when a custom base prompt is configured. Instruct the agent to maintain metadata using grounded project knowledge and propose missing associations before finalizing the summary.
|
||||
- Project approval is an awaited tool call, with cancellation and a ten-minute deadline. Return approval plus project metadata and AGENTS.md only after updating the latest meeting note. Preserve other frontmatter and body content; recheck target and cancellation before writing. Write to a temporary file in the same directory and replace the note only after that write completes, so cancellation or a partial write cannot truncate the note. Existing associations return current context without another prompt.
|
||||
- Use an application-owned background request queue for workflow approvals. The tool returns requested immediately; the queue outlives a summary run. Requests also expire after ten minutes. Only acceptance opens a new settings-agent window and automatically submits the complete detailed prompt. A new conversation avoids overwriting drafts or interrupting an existing agent run.
|
||||
- Reuse the installed native toast toolkit behind a testable approval-prompt interface. Timeouts and cancellation remove pending toasts and invalidate late actions. Shutdown cancels pending approvals; requests are not persisted across process restarts.
|
||||
- Keep tool execution sequential so a blocking project approval cannot be bypassed by concurrent tool execution in the same model response.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- [User ignores project approval] → continue after ten minutes as denied; no project scope or note change.
|
||||
- [User edits the note while a request is pending] → read again after acceptance and append only the project field, retaining all other current fields and notes.
|
||||
- [Project disappears or becomes invalid while waiting] → refuse the association without expanding access.
|
||||
- [Native UI cannot run in automated tests] → test approval, timeout, scope and handoff through controlled prompt/window services and build the Windows target; record hardware/UI verification limits.
|
||||
- [Summarizer completes before workflow approval] → the application queue retains the request until decision, timeout, or shutdown.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
No bulk migration. Existing folders remain discoverable without PROJECT.md, and associated projects gain metadata as the summarizer maintains them. Rollback removes the tools; PROJECT.md and normal meeting associations remain ordinary vault content.
|
||||
|
||||
## Open Questions
|
||||
|
||||
None. Workflow notifications use the same ten-minute validity as project notifications; workflow notification intentions are limited to 100 characters for readability.
|
||||
@@ -0,0 +1,25 @@
|
||||
## Why
|
||||
|
||||
The summarizer cannot currently discover missing project associations or propose workflow improvements with explicit user approval. Project folder names alone do not provide enough context for selecting the right project.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Maintain `PROJECT.md` frontmatter with `name` and a description of at most 256 characters through the summarizer's existing project-file tools.
|
||||
- Include available project metadata alongside bound project instructions and expose the full project metadata catalog through `list_projects`.
|
||||
- Add `request_project_association` with a project ID and a reason of at most 100 characters. Wait up to ten minutes for a native Yes/No notification; approval adds the association and returns project instructions.
|
||||
- Enforce meeting association for summarizer project-file writes as well as reads. Catalog visibility alone does not grant project access.
|
||||
- Add nonblocking `request_workflow_change` with a short intention and detailed scenario/specification. Approval opens a settings-agent conversation and immediately submits the detailed request; the summarizer cannot edit workflows directly.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `summary-agent-requests`: User approval for blocking project association and asynchronous workflow-change handoff.
|
||||
|
||||
### Modified Capabilities
|
||||
- `project-knowledge`: Project identity and discovery metadata in `PROJECT.md`.
|
||||
- `agent-project-tools`: Full metadata catalog and association-scoped writes.
|
||||
- `meeting-summary`: Project metadata in initial instructions and guidance for metadata maintenance and requests.
|
||||
|
||||
## Impact
|
||||
|
||||
Summary tools and agent instructions, project lookup and meeting frontmatter, native Windows notifications, the settings-agent window/prompt submission, DI registration, tests, and workflow/configuration documentation. Existing project IDs remain directory names; no bulk vault migration or live service restart is required.
|
||||
@@ -0,0 +1,91 @@
|
||||
## MODIFIED Requirements
|
||||
### Requirement: Agents can use project context tools
|
||||
Meeting Assistant SHALL expose tools that allow agents to look up project information, retrieve keyword-relevant context, and inspect meeting-derived knowledge.
|
||||
|
||||
Project tools SHALL treat each direct subfolder of the configured projects folder as one project. A meeting note binds projects by listing those subfolder names in the `projects` frontmatter field.
|
||||
|
||||
The summary agent SHALL expose these project tools:
|
||||
|
||||
- `list_projects`
|
||||
- `request_project_association`
|
||||
- `request_workflow_change`
|
||||
- `list_projectfiles`
|
||||
- `read_projectfile`
|
||||
- `write_projectfile`
|
||||
- `list_past_project_meetings`
|
||||
- `read_past_project_meeting_summary`
|
||||
- `search`
|
||||
|
||||
The `search` tool SHALL search the requested current-meeting project scope, or all projects assigned to the current meeting when no project scope is supplied.
|
||||
|
||||
The `search` tool SHALL search both configured project files for the scoped projects and past meeting summary notes in the configured summaries folder whose frontmatter projects intersect the scoped projects.
|
||||
|
||||
The `search` tool SHALL refuse requested project scopes that are not assigned to the current meeting.
|
||||
|
||||
#### Scenario: Agent looks up meeting project context
|
||||
- **WHEN** a meeting note identifies a project
|
||||
- **THEN** the agent can retrieve relevant project context through Meeting Assistant tools
|
||||
|
||||
#### Scenario: Agent discovers the full project catalog
|
||||
- **WHEN** the agent calls `list_projects`
|
||||
- **THEN** it receives every configured project with ID, display name, and description
|
||||
- **AND** this catalog does not grant access to unassociated project files or AGENTS.md
|
||||
|
||||
#### Scenario: Agent reads a clamped project file range
|
||||
- **WHEN** the agent reads a project file with optional line bounds outside the file length
|
||||
- **THEN** `read_projectfile` clamps the requested range to the available file lines without failing
|
||||
|
||||
#### Scenario: Agent searches project knowledge
|
||||
- **WHEN** the agent calls `search` with .NET regular expression keywords
|
||||
- **THEN** Meeting Assistant runs the search against the requested projects or the meeting-bound projects and returns matches as `filename:line text`
|
||||
|
||||
#### Scenario: Agent searches past project meeting summaries
|
||||
- **GIVEN** the current meeting note is assigned to `Project X`
|
||||
- **AND** a prior summary note in the configured summaries folder is assigned to `Project X`
|
||||
- **WHEN** the summary agent searches for a keyword
|
||||
- **THEN** Meeting Assistant returns matches from both `Project X` project files and matching past summary notes
|
||||
|
||||
#### Scenario: Agent search rejects out-of-scope project
|
||||
- **GIVEN** the current meeting note is assigned to `Project X`
|
||||
- **WHEN** the summary agent searches with project scope `Project Z`
|
||||
- **THEN** Meeting Assistant refuses the request because `Project Z` is not assigned to the current meeting
|
||||
|
||||
### Requirement: Agents can write files in existing projects
|
||||
Meeting Assistant SHALL expose a `write_projectfile` tool that can create or update files inside an existing project folder.
|
||||
|
||||
The target project SHALL be an existing direct subfolder of the configured projects folder and SHALL be associated with the current meeting. The target file path SHALL stay inside that project folder. Newly approved associations SHALL take effect immediately for all project tools.
|
||||
|
||||
When no line edit arguments are supplied and `replace_file` is not true, `write_projectfile` SHALL append the supplied content to the file and SHALL create the file when it does not exist.
|
||||
|
||||
When `replace_file` is true, `write_projectfile` SHALL replace the whole file with the supplied content.
|
||||
|
||||
When both `from` and `to` are supplied, `write_projectfile` SHALL replace the inclusive 1-based line range with the supplied content.
|
||||
|
||||
When `insert` is supplied, `write_projectfile` SHALL insert the supplied content at that 1-based line position.
|
||||
|
||||
Meeting Assistant SHALL refuse ambiguous writes that combine `replace_file` with line edit arguments.
|
||||
|
||||
#### Scenario: Project file is appended or created
|
||||
- **WHEN** the agent writes a project file without line edit arguments
|
||||
- **THEN** Meeting Assistant appends the supplied content to an existing file
|
||||
- **AND** creates the file with the supplied content when it does not exist
|
||||
|
||||
#### Scenario: Project file is explicitly replaced
|
||||
- **WHEN** the agent writes a project file with `replace_file` set to true
|
||||
- **THEN** Meeting Assistant writes the supplied content as the complete file content
|
||||
|
||||
#### Scenario: Project file line range is replaced
|
||||
- **WHEN** the agent writes a project file with `from` and `to` line numbers
|
||||
- **THEN** Meeting Assistant replaces the inclusive line range with the supplied content
|
||||
|
||||
#### Scenario: Project file content is inserted
|
||||
- **WHEN** the agent writes a project file with an `insert` line number
|
||||
- **THEN** Meeting Assistant inserts the supplied content at that line position
|
||||
|
||||
#### Scenario: Project file write target is invalid
|
||||
- **WHEN** the target project is missing, is not associated with the meeting, or the target path escapes the project folder
|
||||
- **THEN** Meeting Assistant refuses the project file write
|
||||
|
||||
#### Scenario: Project file write mode is ambiguous
|
||||
- **WHEN** the agent combines `replace_file` with `from`, `to`, or `insert`
|
||||
- **THEN** Meeting Assistant refuses the project file write
|
||||
@@ -0,0 +1,23 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Summary agent receives bound project instructions
|
||||
Meeting Assistant SHALL append a project section for projects bound to the meeting note frontmatter. Each entry SHALL identify the project ID and include its display name and description from PROJECT.md when available. For each bound project with a root AGENTS.md, the entry SHALL also include that file's content. Metadata SHALL appear even when AGENTS.md is absent. Unassociated project instructions SHALL NOT be appended.
|
||||
|
||||
#### Scenario: Project AGENTS files are appended
|
||||
- **GIVEN** the meeting note frontmatter lists projects Alpha and Beta with root AGENTS.md files
|
||||
- **WHEN** the summary agent is created
|
||||
- **THEN** its project section includes both project IDs and their instructions
|
||||
|
||||
#### Scenario: Project metadata without instructions is appended
|
||||
- **GIVEN** a bound project has PROJECT.md metadata but no AGENTS.md
|
||||
- **WHEN** the summary agent is created
|
||||
- **THEN** its entry contains ID, display name and description
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Summarizer maintains project metadata and proposes missing associations
|
||||
Both default and custom summary-agent instructions SHALL explain the full metadata catalog, the distinction between catalog visibility and project access, and the approval process. They SHALL instruct the agent to propose plausible missing associations with concise evidence before finalizing the summary and to maintain associated PROJECT.md name and description (maximum 256 characters). They SHALL explain that workflow improvements require a short intention and a detailed request and are executed only by the settings agent after user approval.
|
||||
|
||||
#### Scenario: Custom base prompt still receives capability guidance
|
||||
- **WHEN** a custom summary base prompt is configured
|
||||
- **THEN** the resulting instructions still explain metadata maintenance, association approvals and workflow-change requests
|
||||
@@ -0,0 +1,18 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Projects have compact discovery metadata
|
||||
Each project SHALL use a root `PROJECT.md` with YAML frontmatter `name` and `description` for agent-maintained discovery metadata. `name` SHALL be the display name; the project ID SHALL remain its direct subfolder name. The summarizer SHALL be instructed to create and maintain this metadata for associated projects from grounded project knowledge, preserving other frontmatter and body content. The description SHALL contain at most 256 characters.
|
||||
|
||||
Catalog lookup SHALL tolerate missing or malformed metadata by falling back to the ID as display name and an empty description. Metadata lookup SHALL NOT grant access to project files or instructions.
|
||||
|
||||
#### Scenario: Project has metadata
|
||||
- **WHEN** a project has valid name and description frontmatter
|
||||
- **THEN** catalog lookup exposes its ID, display name, and description
|
||||
|
||||
#### Scenario: Legacy project has no metadata
|
||||
- **WHEN** a project has no PROJECT.md or no usable frontmatter
|
||||
- **THEN** it remains discoverable with its ID as display name and an empty description
|
||||
|
||||
#### Scenario: Agent writes invalid metadata
|
||||
- **WHEN** the summarizer attempts a PROJECT.md update without valid name/description or with a description longer than 256 characters
|
||||
- **THEN** the write is refused without changing the existing file
|
||||
@@ -0,0 +1,56 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Summarizer can request project association
|
||||
The summarizer SHALL expose `request_project_association` accepting an existing project ID and a nonempty single-line reason of at most 100 characters. Invalid requests SHALL be refused without a notification or file changes.
|
||||
|
||||
The tool SHALL show a native notification identifying the meeting and project, explaining the association request and reason, with Yes/No actions. Tool completion and further summarizer work SHALL wait for the decision for up to ten minutes. No, expiration, notification unavailability, or canceled summarization SHALL NOT add the project. Expiration SHALL remove the notification, invalidate late activation, and return denial.
|
||||
|
||||
Once a stopped run has reached summarization, the recording stop-processing deadline SHALL return control while summary processing continues in the background. It SHALL NOT cancel a summary awaiting approval or queue an already-transcribed recording for offline replay.
|
||||
|
||||
On Yes, the tool SHALL append the canonical project ID to the latest meeting-note projects frontmatter without duplicates, preserving other fields and body. Project tools SHALL immediately honor the updated scope, and the result SHALL report approval with project metadata and the root AGENTS.md content when present. No unapproved AGENTS.md content SHALL be returned. Already associated projects SHALL return their current context without prompting.
|
||||
|
||||
#### Scenario: Approval extends scope during the same summary
|
||||
- **GIVEN** a catalog project is not associated with the meeting
|
||||
- **WHEN** the summarizer requests association and the user chooses Yes
|
||||
- **THEN** the meeting note gains that project and the same agent can read/write it
|
||||
- **AND** the result includes its AGENTS.md if present
|
||||
|
||||
#### Scenario: Denial or timeout preserves scope
|
||||
- **WHEN** the user chooses No or ten minutes elapse
|
||||
- **THEN** the waiting tool reports denial, the notification disappears, and scope and meeting note remain unchanged
|
||||
|
||||
#### Scenario: User edits note during approval
|
||||
- **WHEN** the user changes other meeting frontmatter or notes while an association request waits
|
||||
- **AND** then approves the project
|
||||
- **THEN** the project is added without losing those edits
|
||||
|
||||
#### Scenario: Invalid or stale request cannot grant access
|
||||
- **WHEN** the ID is unknown, reason exceeds 100 characters, the target disappears, or summarization is canceled
|
||||
- **THEN** the request cannot expand project access
|
||||
|
||||
#### Scenario: Stop wait expires while summary approval is pending
|
||||
- **GIVEN** transcription has completed and summarization is waiting for a user decision
|
||||
- **WHEN** the recording stop-processing timeout expires
|
||||
- **THEN** stopping returns with summarization still active
|
||||
- **AND** the summary continues with its own approval deadline without an offline transcription backlog item
|
||||
|
||||
### Requirement: Summarizer can request workflow changes without editing workflows
|
||||
The summarizer SHALL expose `request_workflow_change` accepting a nonempty single-line intention of at most 100 characters and a nonempty detailed change prompt, preferably a scenario or specification. The tool SHALL return requested without waiting for approval, and the summarizer SHALL continue normally without direct workflow-editing capabilities.
|
||||
|
||||
A native notification SHALL show `Workflow change requested: ...` with the intention and Yes/No actions. The detailed prompt SHALL be retained by the application independently of summary completion. No or ten-minute expiration SHALL discard the request without opening the editor or changing workflows. Late activation SHALL have no effect.
|
||||
|
||||
Yes SHALL open a new settings-agent conversation and immediately submit the full detailed prompt once. An existing open conversation or draft SHALL remain intact. Application shutdown SHALL cancel and remove pending notifications.
|
||||
|
||||
#### Scenario: Workflow request does not block the summary
|
||||
- **WHEN** the agent requests a workflow change
|
||||
- **THEN** the tool returns requested while approval remains pending
|
||||
- **AND** the summary can complete without opening the settings agent
|
||||
|
||||
#### Scenario: Approved workflow request starts settings agent
|
||||
- **GIVEN** the summary run has completed and its workflow request is pending
|
||||
- **WHEN** the user chooses Yes
|
||||
- **THEN** the settings-agent window opens and starts the detailed prompt exactly once
|
||||
|
||||
#### Scenario: Denied or expired workflow request does nothing
|
||||
- **WHEN** the user declines or ignores a workflow request for ten minutes
|
||||
- **THEN** its notification disappears and no editor or workflow change is started
|
||||
@@ -0,0 +1,35 @@
|
||||
## 1. Project catalog and metadata
|
||||
|
||||
- [x] 1.1 Test and implement full metadata catalog with legacy/malformed fallback and scoped file access.
|
||||
- [x] 1.2 Test PROJECT.md metadata writes and enforce the description limit without damaging existing files.
|
||||
- [x] 1.3 Include bound metadata beside AGENTS.md and instruct default/custom agents to maintain it and request missing associations.
|
||||
|
||||
## 2. Project approval
|
||||
|
||||
- [x] 2.1 Test blocking approval, immediate scope update, returned AGENTS.md and preservation of concurrent user note edits.
|
||||
- [x] 2.2 Handle invalid IDs/reasons, existing associations, denial, timeout, cancellation and stale actions.
|
||||
- [x] 2.3 Register the tool and native Yes/No notification with ten-minute validity and sequential summary tool execution.
|
||||
- [x] 2.4 Keep summarization alive after the recording stop wait expires so approval does not trigger transcription cancellation or offline replay.
|
||||
|
||||
## 3. Workflow-change requests
|
||||
|
||||
- [x] 3.1 Test and implement nonblocking application-owned workflow requests that survive summary completion.
|
||||
- [x] 3.2 Open a separate settings-agent conversation and automatically submit approved detail; preserve existing drafts and runs.
|
||||
- [x] 3.3 Cover rejection, expiration, shutdown, invalid requests and exactly-once acceptance.
|
||||
|
||||
## 4. Verification
|
||||
|
||||
- [x] 4.1 Update workflow and configuration documentation.
|
||||
- [x] 4.2 Review changed code and surrounding integration; fix actionable findings.
|
||||
- [x] 4.3 Run relevant tests, full solution tests, Windows build and strict OpenSpec validation.
|
||||
- [x] 4.4 Verify through the safest direct operational surface and document native UI/live-provider limits.
|
||||
|
||||
Verification (2026-09-25): all 552 solution tests pass, including 20 focused project/catalog/request tests. The solution builds the Windows target successfully with the four existing NAudio obsolete-API warnings. Strict validation passes for this change and the existing microphone change; `git diff --check` is clean.
|
||||
|
||||
Two independent review passes covered project metadata/access and notification/queue/UI lifecycle, including surrounding recording-stop integration. Incomplete metadata now consistently falls back to the project ID, and traversal coverage uses an associated project so it actually exercises path containment. Project association writes prepare a same-directory temporary file before replacing the meeting note; successful requests leave no temporary file behind.
|
||||
|
||||
Public-tool behavior tests inspect real generated meeting and project files with controlled approval/window services. They verify latest-note preservation, immediate scope changes, returned instructions, rejection/expiry/cancellation, nonblocking workflow requests, and automatic submission of approved detail to a fresh settings-agent conversation. A coordinator regression test verifies that the stop wait cannot cancel a summary awaiting approval or enqueue unnecessary offline replay.
|
||||
|
||||
The running application's recording-status endpoint was checked read-only and reported idle. The service was not updated or restarted. Native toast activation/removal, actual WPF window isolation, and a live model invoking these tools were not exercised, because those require running the new Windows build and interacting with its notifications. Sequential tool execution is configured and compiled; the model pipeline itself was not exercised with simultaneous tool calls. These operational checks remain required before acceptance or archival.
|
||||
|
||||
Authorized local start (2026-09-25): after confirming idle status and logs, the documented restart helper published and started the Release build in `tmp/meeting-assistant-runtime/run-20260925-115711`. `/health` reports `ok`, `/recording/status` reports idle, the tray icon was created, and Resemblyzer warm-up completed without stderr errors. The published application DLL matches the Release output by SHA-256. This verifies startup of the new build; native approval interactions and live-model tool invocation remain unverified.
|
||||
Reference in New Issue
Block a user