feat: propagate Korean prose contract to providers

src/claridoc/prompts.py

@@ -11,6 +11,11 @@ from claridoc.models import (
     Outline,
     SourcePack,
 )
+from claridoc.style_contracts import (
+    mandatory_style_review_checks,
+    revision_style_protocol,
+    style_guidance,
+)
 
 
 FOUNDATION_RULES = """\
@@ -29,25 +34,6 @@ FOUNDATION_RULES = """\
 13. End with the decision the reader should carry into a similar situation, not a generic recap or a checklist added by habit.
 """
 
-WOOWAHAN_TECH_BLOG_KO = """\
-Korean technical-blog operating profile (derived from a bounded sample of Woowahan engineering articles; it is not an official house-style specification):
-- Begin from the team or system's concrete context, then expose the friction in observable terms.
-- Explain why the problem mattered before introducing the selected tool or architecture.
-- Show prior approaches, failed attempts, or realistic alternatives when they affected the decision.
-- State the selection criteria and the reason for the final choice. Pair benefits with the cost or boundary that remained.
-- Let implementation details answer the problem already established; do not turn the article into a component inventory.
-- Connect verification to the original problem. Report only what the available tests or observations actually prove.
-- Treat problem -> constraints -> options -> decision as a semantic order, never as a sentence template. Do not narrate outline labels to the reader.
-- Start a paragraph from a concrete actor, state, change, consequence, or decision when the evidence supports one. Make the subject and impact visible instead of opening with an abstract category label.
-- Do not open consecutive paragraphs with formulaic ordinal frames such as “첫 번째 제약은”, “두 번째 제약은”, and “세 번째 제약은”. Use ordinals for a real sequence, method, layer, or figure; use a list or meaningful subheadings for genuinely parallel items.
-- A question heading or transition must receive an immediate answer in the following prose. Do not use unanswered rhetorical questions as decoration.
-- Use “하지만/다만” only for a real contrast and “이 때문에/그 결과/그래서/이에” only when the referenced cause is explicit in the preceding context.
-- Use “팀에서는/저희는/우리는” when ownership or project-local judgment matters, not as a filler subject and never to universalize a local choice.
-- Use conversational but disciplined Korean. Avoid canned phrases such as “이 절에서는”, “제공된 근거에 따르면”, “독자는 ~할 수 있다”, and repeated “먼저/다음으로/마지막으로”.
-- An “예상 독자” block is optional. Use it only when it materially prevents the wrong audience from reading the article; never insert it as mandatory boilerplate.
-- Revise for flow: when a paragraph feels paused or a connector feels forced, repair the logical relation rather than adding a transition word.
-"""
-
 ROLE_GUIDANCE: dict[str, str] = {
     "logic": "Audit premises, causal links, section order, transitions, contradictions, and whether each conclusion follows from stated constraints and evidence.",
     "reader": "Simulate the declared reader. Audit orientation, missing context, cognitive load, examples, scan paths, and whether process language or internal metadata breaks immersion.",
@@ -62,17 +48,6 @@ def _dump(value: Any) -> str:
     return json.dumps(value, ensure_ascii=False, indent=2)
 
 
-def _style_guidance(brief: Brief) -> str:
-    profile = brief.constraints.style_profile.casefold()
-    if brief.is_korean and brief.document_type.value == "technical_blog" and profile in {
-        "auto",
-        "woowahan_tech_blog_ko",
-        "korean_problem_solving_blog",
-    }:
-        return WOOWAHAN_TECH_BLOG_KO
-    return "Use a reader-facing style appropriate to the document type; never expose planning or evidence-processing scaffolding."
-
-
 def _citation_policy(brief: Brief) -> str:
     style = brief.constraints.citation_style
     if not brief.constraints.require_citations:
@@ -134,7 +109,7 @@ Apply these foundation rules:
 {FOUNDATION_RULES}
 
 Apply this style guidance:
-{_style_guidance(brief)}
+{style_guidance(brief)}
 
 {_source_hierarchy()}
 
@@ -176,7 +151,7 @@ Apply these foundation rules:
 {FOUNDATION_RULES}
 
 Apply this style guidance:
-{_style_guidance(brief)}
+{style_guidance(brief)}
 
 {_source_hierarchy()}
 
@@ -232,7 +207,7 @@ Apply these foundation rules:
 {FOUNDATION_RULES}
 
 Apply this style guidance:
-{_style_guidance(brief)}
+{style_guidance(brief)}
 
 {_source_hierarchy()}
 
@@ -247,6 +222,7 @@ Mandatory checks:
 - The opening must establish a real problem or tension rather than recite audience, scope, and source metadata.
 - Information-architecture labels must not leak as repetitive sentence scaffolding. In Korean technical blogs, distinguish real ordered sequences from formulaic “첫 번째/두 번째/세 번째 + abstract category” paragraph openings.
 - A question heading or transition must be answered immediately, and each contrast or causal connector must point to a real relation in the surrounding prose.
+{mandatory_style_review_checks(brief)}
 
 Scoring dimensions (0-100 each):
 {dimension_list}
@@ -313,7 +289,7 @@ Apply these foundation rules:
 {FOUNDATION_RULES}
 
 Apply this style guidance:
-{_style_guidance(brief)}
+{style_guidance(brief)}
 
 {_source_hierarchy()}
 
@@ -328,6 +304,7 @@ Revision protocol:
 8. Preserve correct material and the author's project context; avoid generic filler and unrelated rewrites.
 9. Remove repeated ordinal sentence scaffolding that merely reads the outline aloud. Preserve ordinals when they identify a real procedure, method, layer, or figure, and prefer a list or meaningful subheadings for parallel items.
 10. Return the entire revised document, not a patch or explanation.
+{revision_style_protocol(brief)}
 
 Citation policy: {_citation_policy(brief)}
 Date policy: {_date_policy(brief)}