Move embedded prompts to PromptKit definitions

docs/internal/prompts.md

@@ -1,62 +1,38 @@
 # Audita Prompt Registry
 
-## Scope
+`internal/prompts` embeds nine PromptKit YAML definitions under
+`assets/prompts`. The IDs and selected version remain:
 
-This document describes embedded prompt assets, prompt metadata, and rendering behavior.
+- `modules.glossary.proposal` (`v1`)
+- `modules.homophones.proposal` (`v1`)
+- `modules.spoken_word.proposal` (`v1`)
+- `modules.grammar.proposal` (`v1`)
+- `validators.spoken_form_plausibility` (`v1`)
+- `validators.meaning_reversal_review` (`v1`)
+- `validators.editorial_review` (`v1`)
+- `validators.grammar_review` (`v1`)
+- `validators.spoken_word_review` (`v1`)
 
-## Registry Ownership
+PromptKit reads the embedded definitions and renders their system and user
+messages from named string variables. The role-bound adapter will supply
+`HardeningPolicy` from the single embedded `assets/shared/prompt_hardening.md`
+fragment after caller variables, so callers cannot replace that policy. Proposal prompts receive the
+section JSON, glossary JSON where used, and transcript description block.
+Validator prompts receive the correction payload and description block.
+The prompt assets retain the prior task instructions and output-schema
+association. The role-bound runtime will supply the complete JSON Schema output contract
+and repair count; the definition does not own an operator-facing repair default.
 
-Prompt registry lives in `internal/prompts` and embeds assets under `internal/prompts/assets/**`.
+`internal/framework/responseschema` remains the only embedded source for
+`correction_set.v1.json` and `validator_decision_set.v1.json`. It exposes that
+filesystem to PromptKit and retains Audita's schema-key lookup. PromptKit's
+prepared execution supplies definition and rendered hashes; Audita does not
+recompute or promise equality with hashes from the removed template renderer.
+The small Audita registry records only prompt ID, version, source, and embedded
+path. Prepared runtime metadata belongs in diagnostics rather than the registry.
 
-Registered prompt IDs:
-- `modules.glossary.proposal`
-- `modules.homophones.proposal`
-- `modules.spoken_word.proposal`
-- `modules.grammar.proposal`
-- `validators.spoken_form_plausibility`
-- `validators.meaning_reversal_review`
-- `validators.editorial_review`
-- `validators.grammar_review`
-- `validators.spoken_word_review`
-
-## Metadata Model
-
-Each prompt has metadata:
-- `prompt_id`
-- `prompt_version`
-- `prompt_source`
-- `embedded_path`
-- `sha256`
-
-Current source/version values:
-- `prompt_source = builtin`
-- `prompt_version = v1`
-
-## Rendering
-
-`prompts.RenderUserSystem(promptID, data)` renders system/user templates.
-
-Template behavior:
-- uses Go `text/template`;
-- `missingkey=error` is enabled;
-- output is trimmed.
-
-A shared hardening fragment is embedded once and referenced by prompt templates.
-
-## Prompt Context Inputs
-
-Shared prompt payload helpers:
-- transcript section JSON (`internal/framework/promptcontext/MarshalTranscriptSectionJSON`)
-- transcript description block (`TranscriptDescriptionBlock`)
-
-Modules and LLM validators provide typed data maps to render prompt assets.
-
-## Diagnostics Integration
-
-Prompt metadata is attached to proposal/validator diagnostics request metadata using `Metadata.DiagnosticsMap()`.
-
-## Key Tests
-
-- `internal/prompts/registry_test.go`
-- `internal/framework/promptcontext/*_test.go`
-- module and validator prompt builder tests
+The structured-call contract carries prompt ID/version, string variables,
+response-schema key, and logical-call attribution. Module and validator callers
+are being migrated in their respective work units. See the
+[LLM runtime](llm-runtime.md) for runtime assembly and
+[configuration](../config.md) for operator-selected profiles.