curo/kite
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(07): create phase plan — 5 plans, verification passed

Browse Source 
5 waves: system_settings DB + HKDF encryption (01), ProviderConfig +
GenericOpenAIProvider + singleton client fix (02), Anthropic output_config +
classifier wiring (03), Celery retry 30/90/270s + re-queue endpoint (04),
admin AI panel + DocumentCard badge + human checkpoint (05).

All 18 decisions D-01..D-18 covered. Plan checker passed after 1 revision
round (4 blockers fixed: D-02/D-14 coverage, D-11 Vitest tests, Plan 05
files_modified).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
curo1305
2026-06-03 18:25:00 +02:00
co-authored by Claude Sonnet 4.6
parent 6c8e0d8bde
commit 3df62506c9
11 changed files with 2328 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phases/07-redo-and-optimize-llm-integration/07-RESEARCH.md
+4 -1
View File
@@ -837,22 +837,25 @@ This was added in a prior phase. D-14 requires no docker-compose changes. The LM
---
## Open Questions
## Open Questions (RESOLVED)
1. **xAI/Grok and DeepSeek JSON mode verification**
- What we know: Both claim OpenAI-compat; industry pattern suggests they support `json_object`
- What's unclear: Neither was directly verified against official docs in this research session
- Recommendation: Planner should include a Wave 0 task to spot-check against official xAI and DeepSeek API docs, or treat both as [ASSUMED] and add `supports_json_mode` flag that defaults to `True` but can be overridden
- RESOLVED: treated as [ASSUMED]; supports_json_mode flag is the mitigation — planner accepts the risk. xAI and DeepSeek are configured with supports_json_mode=True in Plan 02; if a future user reports JSON-shape failures, flipping the SUPPORTS_JSON_MODE entry to False routes that provider through parse_classification() (D-02 fallback path). No blocking action required for Phase 7 execution.
2. **anthropic SDK minimum version for output_config**
- What we know: `output_config` is confirmed in current SDK (0.105.2) with no beta headers needed
- What's unclear: The exact version when `output_config` was introduced (the old `output_format`/beta-header path still works)
- Recommendation: Bump `requirements.txt` to `anthropic>=0.95.0` as part of Wave 1; if `output_format` param (old alias) is still working, the older SDK might work too — but it's safer to pin to a known good version
- RESOLVED: treated as [ASSUMED]; supports_json_mode flag is the mitigation — planner accepts the risk. Plan 02 pins anthropic>=0.95.0 in requirements.txt; if a stricter floor is needed it can be raised in a follow-up phase. The fallback path (parse_classification) handles any output_config regression.
3. **Gemini-compat: use json_object or fall back?**
- What we know: The OpenAI-compat endpoint does NOT document `json_object` string mode; it supports Pydantic schema via `client.beta.chat.completions.parse()`
- What's unclear: Whether `json_object` is silently ignored or raises an error
- Recommendation: Implement Gemini preset with `supports_json_mode=False`; `GenericOpenAIProvider.classify()` skips `response_format` for these presets and relies on `parse_classification()` fallback
- RESOLVED: treated as [ASSUMED]; supports_json_mode flag is the mitigation — planner accepts the risk. Plan 02 SUPPORTS_JSON_MODE["gemini"] = False routes Gemini through the parse_classification() fallback path. Test test_gemini_fallback_to_parse_classification in Plan 02 Task 4 enforces this contract.
---