feat: wire real LLM runner via third-one or OpenAI-compatible API

This commit is contained in:
user
2026-04-28 15:48:37 +09:00
parent 9b0bc172ef
commit dced20a9af
8 changed files with 486 additions and 5 deletions

View File

@@ -56,3 +56,30 @@ boundary.
- **WHEN** it invokes the workflow layer
- **THEN** it calls a typed Go interface
- **AND** does not mutate product state by parsing freeform shell output.
### Requirement: LLM runner calls OpenAI-compatible API
The system SHALL provide an LLM-based workflow runner that implements the
Runner interface by calling an OpenAI-compatible chat completions API when
TUTOR_LLM_API_KEY is configured.
#### Scenario: grader uses LLM when configured
- **GIVEN** TUTOR_LLM_API_KEY and TUTOR_LLM_ENDPOINT are set
- **WHEN** the server starts
- **THEN** an LLMRunner wraps the configured model
- **AND** GradeInterviewAnswer calls the LLM with a structured grading prompt
- **AND** the response is parsed into the typed GradedAnswer contract.
#### Scenario: memory extraction uses LLM when configured
- **GIVEN** an LLM runner is active
- **WHEN** ExtractLearningMemory is called with a graded answer
- **THEN** the LLM produces MemoryUpdateCandidate with concept mastery, misconception, intervention, and review schedule updates.
#### Scenario: falls back to stub when unconfigured
- **GIVEN** TUTOR_LLM_API_KEY is empty
- **WHEN** the server starts
- **THEN** a StubRunner is used
- **AND** grading and memory extraction produce deterministic stub output.