Jan Svabenik 0f29856343 docs: document database snapshot commit policy		1 个月前
cmd/qctextbuilder	Initial QC Text Builder MVP scaffold	1 个月前
data	chore: snapshot local database state	1 个月前
dist	Add prompt settings and draft prompt context	1 个月前
docs	chore: add configurable log levels for diagnostics	1 个月前
internal	chore: add configurable log levels for diagnostics	1 个月前
migrations	Initial QC Text Builder MVP scaffold	1 个月前
test/integration	Initial QC Text Builder MVP scaffold	1 个月前
web	feat: add llm runtime tuning and validation	1 个月前
.env.local	Initial QC Text Builder MVP scaffold	1 个月前
AGENTS.md	docs: document database snapshot commit policy	1 个月前
README.md	chore: add configurable log levels for diagnostics	1 个月前
build-local.ps1	Initial QC Text Builder MVP scaffold	1 个月前
concept.json	Initial QC Text Builder MVP scaffold	1 个月前
go.mod	Add SQLite persistence and draft review flow	1 个月前
go.sum	Add SQLite persistence and draft review flow	1 个月前
run-local.ps1	fix: preserve provider suggestions over stale fallback state	1 个月前

README.md

QC Text Builder (Go)

QC Text Builder ist eine Go-Anwendung fuer den kontrollierten QC-Textprozess von Template bis Site-Build.

Aktueller Stand

Die App kann heute:

AI-Templates aus QC synchronisieren und anzeigen.
Templates onboarden (Discovery/Manifest) und Felder fuer Mapping/Review bearbeiten.
Drafts anlegen, aktualisieren und im Status draft -> reviewed -> submitted fuehren.
Externen Draft-Intake ueber POST /api/drafts/intake verarbeiten (Stammdaten + optional Website-/Stilkontext, kein Direkt-Build).
Globalen Master-Prompt in Settings pflegen sowie Prompt-Bloecke fuer den spaeteren LLM-Flow als Standard konfigurieren.
Im Settings-/Config-Bereich die LLM-Basiskonfiguration pflegen: aktiver Provider, aktives Modell (provider-aware statische Auswahlliste), Base URL fuer Ollama/kompatible Endpoints, Temperature/Max Tokens sowie getrennte API-Key-Speicher je Provider (OpenAI, Anthropic, Google, xAI, Ollama).
LLM-Provider-Konfiguration in Settings per leichtgewichtigem Validate-Action pruefen (aktiver Provider/Modell/Key/Base URL via kurzem Runtime-Request).
OpenAI-kompatible Runtime-Requests waehlen den Token-Limit-Parameter intern modellkompatibel (max_completion_tokens fuer OpenAI GPT-5-Modelle, sonst max_tokens), inkl. Settings-Validate-Action.
OpenAI-kompatible Runtime-Responses werden robust ueber mehrere Chat-/GPT-5-kompatible Content-Shapes extrahiert (u. a. choices[].message.content als String/Part-Array sowie output_text/output[].content); bei leerem Ergebnis werden nur sichere, priorisierte Strukturdiagnosen (inkl. choices/message-Shapes, message.content-Typ/Laenge und finish_reason falls vorhanden), keine Prompt-/Secret-Inhalte, zurueckgegeben.
Im Draft-/Build-UI den User-Flow auf Stammdaten, Intake-/Website-Kontext, Stil-Auswahl und Template-Felder fokussieren; Prompt-Interna liegen in Settings.
Interne semantische Zielslots (z. B. hero.title, service_items[n].description) auf Template-Felder abbilden als Vorbereitung fuer spaeteren LLM-Autofill.
Repeated-Bereiche in semantischen Slots werden block-/rollenbasiert getrennt (z. B. Services/Team/Testimonials pro Item statt Sammel-Slot).
LLM-first Autofill-Vorschlaege ueber provider-aware Runtime (OpenAI, Anthropic, Google, xAI, Ollama/kompatibel) mit aktiver Provider-/Modell-Auswahl aus Settings, strukturierter Feldzuordnung auf fieldPath/Slot und Rule-based Fallback fuer Ausfall-/Testfaelle.
Composite-Fallback laeuft nur fuer echte Zielfeld-Luecken: bei voller Primaerabdeckung kein Fallback-Aufruf, bei Teilabdeckung nur fuer fehlende fieldPaths; Primaer-Sources bleiben bei Merge priorisiert.
Suggestion-Workflow getrennt von Feldwerten (Preview), inkl. Generate all, Regenerate all, Apply all to empty sowie per-Feld Apply/Regenerate im Draft-/Build-UI.
Technische Felddetails (z. B. fieldPath, Suggestion-Metadaten, Slot-Preview) sind im UI standardmaessig ausgeblendet und nur per Debug-Toggle sichtbar.
Strukturierte Autofill-/LLM-Logs mit operativen Zusammenfassungen auf INFO (Provider-Pfad, Fallback-Status, Validate-Action, Dauer, Suggestion-Count).
Vertiefte Provider-/Runtime-Diagnostik (Prompt-/Payload-/Response-/Extract-/Parse-Snippets, Samples, Feld-Transition-Details) bleibt erhalten und ist ueber LOG_LEVEL=debug sichtbar; API-Key-/Authorization-Daten bleiben redigiert.
Kleine interne Log-API GET /api/logs?limit=<n> fuer aktuelle In-Memory-Logeintraege (Ring-Buffer, neueste zuerst).
Builds aus geprueften Daten starten sowie Job-Status pollen und Editor-URL nachladen.

Wichtig:

Leadharvester liefert nur Intake-Daten (Stammdaten + optional Kontext) in Drafts.
LLM-Autofill bleibt Assistenz im Review-Flow: Vorschlaege werden separat gespeichert und manuell angewendet; bei Provider-Ausfall greift ein Fallback-Pfad (QC-kompatibel, danach deterministisch Rule-based).
Provider-/Modell-/Base-URL/API-Key/Temperature/Max-Tokens-Settings steuern den primaeren Suggestion-Runtimepfad produktiv.

Lokaler Start

Env setzen:
- HTTP_ADDR=:8080
- DB_DRIVER=sqlite (Default)
- DB_URL=data/qctextbuilder.db (Default)
- QC_BASE_URL=https://qc-api.yggdrasil.dev-mono.net/api/v1
- QC_TOKEN=<bearer token>
- optional: LOG_LEVEL=info|debug|warn|error (Default info; fuer tiefe Autofill-/Provider-Diagnostik debug)
- optional: LOG_FILE=logs/qctextbuilder.log fuer zusaetzliches JSON-Logfile (stdout bleibt aktiv)
Starten:
- go run ./cmd/qctextbuilder

Persistenz

Default ist SQLite. Gespeichert werden Settings (inkl. Prompt-Konfig und LLM-Provider-/Modell-/Runtime-/Key-Grundlagen), Templates, Manifeste/Felder, Drafts und Site-Builds.

Draft-/Review-Flow

Empfohlener Ablauf:

Draft anlegen oder via Intake vorbefuellen.
Inhalte im UI/API pruefen und anpassen.
Draft auf reviewed setzen.
Build starten; Draft wird auf submitted fortgeschrieben.

Weiterfuehrende Projektdoku

Zielbild, Roadmap und Ausbaustufen stehen hier:

docs/TARGET_STATE_AND_ROADMAP.md

Projektlokale Agentenleitplanken stehen hier:

AGENTS.md