Jan Svabenik 8ffcac06b4 chore: snapshot local database state		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	Prepare draft intake and LLM context flow	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