Public Access
79 lines
4.0 KiB
Markdown
79 lines
4.0 KiB
Markdown
# Repository Instructions
|
|
|
|
## Project Orientation
|
|
|
|
Meeting Assistant is a spec-driven .NET service for capturing, transcribing, summarizing, and enriching meetings without depending on a specific meeting platform API. When starting work in this repository, read `README.md` first for the current runtime architecture, then read the OpenSpec documents so you understand the current scope and capabilities before changing code:
|
|
|
|
- `README.md`
|
|
- `openspec/config.yaml`
|
|
- all specs under `openspec/specs`
|
|
- all active change specs under `openspec/changes/*/specs`
|
|
- active change `proposal.md`, `design.md`, and `tasks.md` only when more context is needed
|
|
|
|
Do not treat implementation code as the only source of truth. Requirements belong in OpenSpec changes.
|
|
|
|
## Start Work Checklist
|
|
|
|
Before editing specs or code, do the following:
|
|
|
|
1. Run `git status --short` and note existing user or agent changes.
|
|
2. Identify whether there is an active OpenSpec change relevant to the request.
|
|
3. Read the relevant specs before reading implementation details.
|
|
4. Decide whether the request belongs to an existing change or needs a new change.
|
|
5. State that decision and the reason before editing requirements or code.
|
|
|
|
## Development Cycle
|
|
|
|
Use the `$tdd` skill for feature work and bug fixes. Work in small vertical slices:
|
|
|
|
1. Add or update the relevant OpenSpec requirement/scenario.
|
|
2. Add one failing behavior test through the public interface.
|
|
3. Implement the minimum code needed to pass that test.
|
|
4. Repeat for the next behavior.
|
|
5. Refactor only after tests are green.
|
|
6. Run the relevant tests and `openspec validate <change-id> --strict`.
|
|
|
|
Tests should describe observable behavior and avoid coupling to implementation details.
|
|
|
|
For feature/spec work, keep the active OpenSpec `tasks.md` current enough that another agent can resume the work. Add or update task entries for meaningful behavior changes, but skip task churn for tiny documentation, config, or mechanical maintenance edits.
|
|
|
|
## OpenSpec Change Policy
|
|
|
|
If the user explicitly asks to create a new change, create one.
|
|
|
|
If the user does not explicitly say whether to create a new change, decide from context:
|
|
|
|
- If an open change is already being worked in the current session and the user's request concerns that same behavior, treat it as part of that change.
|
|
- If there is no open change, create a new OpenSpec change for behavior or requirement changes unless the request is very small or not a spec change.
|
|
- Documentation-only edits, deployment variable fixes, build plumbing, and similarly narrow maintenance work usually do not need a new spec change.
|
|
- Bug fixes should still start with a failing test. The required behavior should be added as an addendum to the original spec/change that defined the intended behavior, rather than as an unrelated new requirement.
|
|
|
|
When in doubt, make the reasoning explicit before editing specs or code.
|
|
|
|
## Change Completion
|
|
|
|
A spec/change is not considered done merely because code is merged, tests pass, or `openspec validate` succeeds. A change is ready to be accepted or archived only after the agent has verified the intended behavior through the most direct operational surface available.
|
|
|
|
For Meeting Assistant, prefer verification through:
|
|
|
|
- local application endpoints
|
|
- generated or updated meeting note files
|
|
- transcription and summarization behavior tests
|
|
- application logs proving the end-to-end flow
|
|
|
|
If production or end-to-end verification is not possible, state exactly why and what lower-level verification was performed instead.
|
|
|
|
## Implementation Notes
|
|
|
|
Keep source and deployment ownership separate:
|
|
|
|
- `Manuel/meeting-assistant` owns application source, tests, build configuration, container image publishing, and OpenSpec source changes.
|
|
- A future deployment repository, if created, should own Docker Compose, Traefik labels, secrets/variables, networks, and live image tag selection.
|
|
|
|
Before finishing code changes, run the narrowest useful test command first. For broader changes, run:
|
|
|
|
```powershell
|
|
dotnet test MeetingAssistant.slnx
|
|
openspec validate <change-id> --strict
|
|
```
|