From bbc71434523be5d4efeb9634bd0432136b62f0b4 Mon Sep 17 00:00:00 2001 From: ComBba Date: Mon, 9 Feb 2026 15:56:09 +0900 Subject: [PATCH 1/2] feat(group-a): Foundation for Fairthon 75-Technique system (#224, #225, #226, #227) - #224: Remove input_source field, add fairthon_source for YAML preservation - Remove filter_techniques() and determine_available_inputs() from loader - Add get_all_techniques() and has_readme_content() to registry - #225: Replace 75 Korean YAML technique definitions with English Fairthon templates - Map Fairthon categories to wine-themed folder names - Remove nameKo field from schema and all YAMLs - #226: Unify EvaluationMode enum as single source of truth - Remove duplicate EvaluationMode from models/graph.py - Replace SIX_HATS with SIX_SOMMELIERS everywhere - Add FULL_TECHNIQUES mode - Update frontend TypeScript types - #227: Define BMAD 17-item evaluation canon (A1-D4, 100 points) - Create backend/app/criteria/ module with bmad_items.py - A=25pts, B=25pts, C=30pts, D=20pts - Fix pre-existing auth test failures (7 tests) - Update _check_ownership tests for 3-param signature - Fix Secure cookie assertion for localhost environment Closes #224, Closes #225, Closes #226, Closes #227 --- backend/app/api/routes/graph.py | 28 +- backend/app/core/config.py | 1 + backend/app/criteria/__init__.py | 1 + backend/app/criteria/bmad_items.py | 343 ++++++++++++++++++ backend/app/graph/graph_factory.py | 15 +- backend/app/models/graph.py | 25 +- backend/app/services/evaluation_service.py | 11 +- backend/app/services/graph_builder.py | 10 +- backend/app/techniques/__init__.py | 8 +- .../techniques/definitions/aroma/5w1h.yaml | 47 ++- .../aroma/assumption-reversal.yaml | 43 +-- .../definitions/aroma/constraint-mapping.yaml | 43 +-- .../definitions/aroma/data-mining.yaml | 43 +-- .../definitions/aroma/fact-checking.yaml | 43 ++- .../definitions/aroma/failure-analysis.yaml | 41 +-- .../definitions/aroma/five-whys.yaml | 43 +-- .../definitions/aroma/mind-mapping.yaml | 43 +-- .../aroma/morphological-analysis.yaml | 43 +-- .../definitions/aroma/pestle-analysis.yaml | 49 ++- .../definitions/aroma/question-storming.yaml | 43 +-- .../balance/chaos-engineering.yaml | 43 +-- .../balance/decision-tree-mapping.yaml | 43 +-- .../balance/ecosystem-thinking.yaml | 43 +-- .../balance/evolutionary-pressure.yaml | 43 +-- .../balance/porters-five-forces.yaml | 47 ++- .../balance/resource-constraints.yaml | 43 +-- .../balance/technology-readiness-level.yaml | 55 ++- .../definitions/balance/trait-transfer.yaml | 43 +-- .../definitions/body/anti-solution.yaml | 45 ++- .../definitions/body/devil-advocate.yaml | 43 +-- .../app/techniques/definitions/body/fmea.yaml | 51 ++- .../definitions/body/pre-mortem.yaml | 43 +-- .../body/reverse-brainstorming.yaml | 43 +-- .../definitions/body/risk-matrix.yaml | 25 +- .../definitions/body/swot-analysis.yaml | 55 ++- .../definitions/body/zombie-apocalypse.yaml | 43 +-- .../cellar/balanced-scorecard.yaml | 57 ++- .../cellar/business-model-canvas.yaml | 57 ++- .../cellar/consensus-building.yaml | 43 ++- .../definitions/cellar/indigenous-wisdom.yaml | 43 +-- .../definitions/cellar/meta-analysis.yaml | 43 +-- .../definitions/cellar/priority-matrix.yaml | 25 +- .../definitions/cellar/six-thinking-hats.yaml | 47 ++- .../cellar/synthesis-framework.yaml | 43 +-- .../finish/alien-anthropologist.yaml | 43 +-- .../finish/body-wisdom-dialogue.yaml | 45 ++- .../definitions/finish/emotional-journey.yaml | 43 +-- .../definitions/finish/empathy-mapping.yaml | 43 +-- .../finish/first-impression-analysis.yaml | 47 ++- .../definitions/finish/gut-check.yaml | 47 ++- .../finish/inner-child-conference.yaml | 43 +-- .../definitions/finish/jobs-to-be-done.yaml | 47 ++- .../definitions/finish/kano-model.yaml | 49 ++- .../definitions/finish/persona-journey.yaml | 43 +-- .../definitions/finish/role-playing.yaml | 43 +-- .../finish/sensory-exploration.yaml | 43 +-- .../palate/analogical-thinking.yaml | 43 +-- .../definitions/palate/biomimicry.yaml | 43 +-- .../definitions/palate/concept-blending.yaml | 43 +-- .../definitions/palate/cross-pollination.yaml | 44 +-- .../definitions/palate/design-thinking.yaml | 47 ++- .../palate/first-principles-thinking.yaml | 43 +-- .../definitions/palate/lateral-thinking.yaml | 43 +-- .../palate/provocation-technique.yaml | 45 ++- .../palate/quantum-superposition.yaml | 45 ++- .../palate/random-stimulation.yaml | 43 +-- .../palate/reversal-inversion.yaml | 43 +-- .../definitions/palate/scamper.yaml | 51 ++- .../techniques/definitions/palate/triz.yaml | 47 ++- .../terroir/drunk-history-retelling.yaml | 43 +-- .../terroir/emotion-orchestra.yaml | 43 +-- .../definitions/terroir/metaphor-mapping.yaml | 43 +-- .../terroir/mythic-frameworks.yaml | 43 +-- .../terroir/time-travel-talk-show.yaml | 43 +-- .../vintage/future-self-interview.yaml | 43 +-- .../techniques/definitions/vintage/okr.yaml | 47 ++- .../vintage/opportunity-spotting.yaml | 43 ++- .../vintage/permission-giving.yaml | 43 +-- .../definitions/vintage/plus-points.yaml | 45 ++- .../vintage/scenario-planning.yaml | 49 ++- .../vintage/strength-analysis.yaml | 43 ++- .../definitions/vintage/value-mapping.yaml | 49 ++- .../vintage/what-if-scenarios.yaml | 43 +-- .../definitions/vintage/yes-and-building.yaml | 43 +-- backend/app/techniques/loader.py | 30 +- backend/app/techniques/registry.py | 59 ++- backend/app/techniques/schema.py | 17 +- backend/tests/conftest.py | 5 +- .../fixtures/graph/valid_reactflow_graph.json | 4 +- backend/tests/test_auth_scope.py | 4 +- backend/tests/test_bmad_items.py | 82 +++++ backend/tests/test_graph_api.py | 138 +++---- backend/tests/test_graph_cache.py | 10 +- backend/tests/test_graph_contracts.py | 47 ++- backend/tests/test_graph_factory.py | 3 + backend/tests/test_multi_mode.py | 26 +- backend/tests/test_technique_loading.py | 284 +++++++++++++++ backend/tests/test_techniques_loader.py | 42 +-- backend/tests/test_yaml_english.py | 81 +++++ frontend/src/types/index.ts | 2 +- 100 files changed, 2601 insertions(+), 2001 deletions(-) create mode 100644 backend/app/criteria/__init__.py create mode 100644 backend/app/criteria/bmad_items.py create mode 100644 backend/tests/test_bmad_items.py create mode 100644 backend/tests/test_technique_loading.py create mode 100644 backend/tests/test_yaml_english.py diff --git a/backend/app/api/routes/graph.py b/backend/app/api/routes/graph.py index ea557a3..74718c0 100644 --- a/backend/app/api/routes/graph.py +++ b/backend/app/api/routes/graph.py @@ -21,15 +21,15 @@ } from app.core.exceptions import CorkedError, EmptyCellarError from app.database.repositories.evaluation import EvaluationRepository +from app.graph.graph_factory import EvaluationMode from app.models.graph import ( ReactFlowGraph, TraceEvent, ModeResponse, - EvaluationMode, Graph3DPayload, ) from app.services.graph_builder import ( - build_six_hats_topology, + build_six_sommeliers_topology, build_full_techniques_topology, ) from app.services.graph_builder_3d import build_3d_graph @@ -66,11 +66,11 @@ def _check_ownership(evaluation: dict[str, Any], user, evaluation_id: str) -> No # Allow access to public demo evaluations without auth if evaluation_id in PUBLIC_DEMO_EVALUATIONS: return - + # Require auth for non-public evaluations if user is None: raise CorkedError("Authentication required to view this evaluation") - + if evaluation.get("user_id") != user.id: raise CorkedError( "Access denied: evaluation belongs to another user", status_code=403 @@ -84,14 +84,16 @@ def _determine_mode(evaluation: dict[str, Any]) -> EvaluationMode: evaluation: The evaluation document. Returns: - EvaluationMode (six_hats or full_techniques). + EvaluationMode (six_sommeliers, grand_tasting, or full_techniques). """ - # Check for explicit mode in evaluation data - mode = evaluation.get("mode") + # Check for explicit evaluation_mode first, then fall back to mode + mode = evaluation.get("evaluation_mode") or evaluation.get("mode") if mode == EvaluationMode.FULL_TECHNIQUES.value: return EvaluationMode.FULL_TECHNIQUES - # Default to six_hats mode - return EvaluationMode.SIX_HATS + if mode == EvaluationMode.GRAND_TASTING.value: + return EvaluationMode.GRAND_TASTING + # Default to six_sommeliers mode + return EvaluationMode.SIX_SOMMELIERS @router.get("/{evaluation_id}/graph", response_model=ReactFlowGraph) @@ -133,7 +135,7 @@ async def get_graph( if mode == EvaluationMode.FULL_TECHNIQUES: graph = build_full_techniques_topology() else: - graph = build_six_hats_topology() + graph = build_six_sommeliers_topology() logger.info(f"[Graph] Returning {mode.value} graph for {evaluation_id}") return graph @@ -160,7 +162,7 @@ async def get_graph_structure( if mode == EvaluationMode.FULL_TECHNIQUES: graph = build_full_techniques_topology() else: - graph = build_six_hats_topology() + graph = build_six_sommeliers_topology() return graph @@ -186,7 +188,7 @@ async def get_graph_execution( if mode == EvaluationMode.FULL_TECHNIQUES: graph = build_full_techniques_topology() else: - graph = build_six_hats_topology() + graph = build_six_sommeliers_topology() methodology_trace = evaluation.get("methodology_trace", []) if methodology_trace: @@ -268,7 +270,7 @@ async def get_mode( ) -> ModeResponse: """Get current evaluation mode. - Returns the evaluation mode (six_hats or full_techniques) + Returns the evaluation mode (six_sommeliers, grand_tasting, or full_techniques) for the specified evaluation. Public demo evaluations can be accessed without authentication. diff --git a/backend/app/core/config.py b/backend/app/core/config.py index 6e8ff3b..c807b1c 100644 --- a/backend/app/core/config.py +++ b/backend/app/core/config.py @@ -38,6 +38,7 @@ class Settings(BaseSettings): # LLM APIs GEMINI_API_KEY: str = "" + OPENAI_API_KEY: str = "" # Vertex AI Express (API key auth) VERTEX_API_KEY: str = "" diff --git a/backend/app/criteria/__init__.py b/backend/app/criteria/__init__.py new file mode 100644 index 0000000..04b9465 --- /dev/null +++ b/backend/app/criteria/__init__.py @@ -0,0 +1 @@ +"""Evaluation criteria module for BMAD 17-item scoring system.""" diff --git a/backend/app/criteria/bmad_items.py b/backend/app/criteria/bmad_items.py new file mode 100644 index 0000000..a4b123f --- /dev/null +++ b/backend/app/criteria/bmad_items.py @@ -0,0 +1,343 @@ +"""BMAD 17-item evaluation canon definitions.""" + +from dataclasses import dataclass +from typing import Dict, List + + +@dataclass(frozen=True) +class BMADItem: + """Single BMAD evaluation item.""" + + item_id: str + name: str + description: str + max_score: int + category: str + rubric: Dict[int, str] + + +@dataclass(frozen=True) +class BMADCategory: + """BMAD evaluation category.""" + + category_id: str + name: str + max_score: int + items: List[str] + + +# Category A — Problem Definition (25 pts) +_A1 = BMADItem( + item_id="A1", + name="Problem Clarity", + description="How clearly is the problem defined?", + max_score=7, + category="A", + rubric={ + 1: "Problem unclear/missing", + 3: "Problem partially defined", + 5: "Problem clearly stated", + 7: "Exceptional clarity with context, scope, and constraints", + }, +) + +_A2 = BMADItem( + item_id="A2", + name="Target User Identification", + description="Who are the target users?", + max_score=6, + category="A", + rubric={ + 1: "No users identified", + 3: "Users vaguely described", + 5: "Users well-identified", + 6: "Detailed personas with needs analysis", + }, +) + +_A3 = BMADItem( + item_id="A3", + name="Problem Significance", + description="Why does this problem matter?", + max_score=6, + category="A", + rubric={ + 1: "Significance unclear", + 3: "Some importance shown", + 5: "Clear significance demonstrated", + 6: "Compelling case with data/evidence", + }, +) + +_A4 = BMADItem( + item_id="A4", + name="Existing Solutions Analysis", + description="What alternatives exist?", + max_score=6, + category="A", + rubric={ + 1: "No analysis of alternatives", + 3: "Basic competitor mention", + 5: "Good competitive analysis", + 6: "Thorough analysis with differentiation", + }, +) + +# Category B — Technical Design (25 pts) +_B1 = BMADItem( + item_id="B1", + name="Architecture Design", + description="System architecture quality.", + max_score=7, + category="B", + rubric={ + 1: "No architecture", + 3: "Basic structure", + 5: "Well-designed architecture", + 7: "Exceptional architecture with clear patterns", + }, +) + +_B2 = BMADItem( + item_id="B2", + name="Technology Choice", + description="Appropriateness of tech stack.", + max_score=6, + category="B", + rubric={ + 1: "Inappropriate choices", + 3: "Adequate choices", + 5: "Well-reasoned choices", + 6: "Optimal choices with justification", + }, +) + +_B3 = BMADItem( + item_id="B3", + name="Scalability Consideration", + description="Growth planning.", + max_score=6, + category="B", + rubric={ + 1: "No scalability thought", + 3: "Basic scalability", + 5: "Good scalability planning", + 6: "Comprehensive scalability strategy", + }, +) + +_B4 = BMADItem( + item_id="B4", + name="Security Design", + description="Security measures.", + max_score=6, + category="B", + rubric={ + 1: "No security consideration", + 3: "Basic security", + 5: "Good security practices", + 6: "Comprehensive security architecture", + }, +) + +# Category C — Implementation (30 pts) +_C1 = BMADItem( + item_id="C1", + name="Code Quality", + description="Code cleanliness and standards.", + max_score=7, + category="C", + rubric={ + 1: "Poor code quality", + 3: "Basic code quality", + 5: "Good code quality", + 7: "Exceptional code quality with best practices", + }, +) + +_C2 = BMADItem( + item_id="C2", + name="Testing Coverage", + description="Test quality and coverage.", + max_score=6, + category="C", + rubric={ + 1: "No tests", + 3: "Basic tests", + 5: "Good test coverage", + 6: "Comprehensive testing strategy", + }, +) + +_C3 = BMADItem( + item_id="C3", + name="Error Handling", + description="Robustness.", + max_score=6, + category="C", + rubric={ + 1: "No error handling", + 3: "Basic error handling", + 5: "Good error handling", + 6: "Comprehensive error handling with recovery", + }, +) + +_C4 = BMADItem( + item_id="C4", + name="Performance Optimization", + description="Performance considerations.", + max_score=5, + category="C", + rubric={ + 1: "No optimization", + 3: "Basic optimization", + 5: "Well-optimized with benchmarks", + }, +) + +_C5 = BMADItem( + item_id="C5", + name="CI/CD & DevOps", + description="Deployment pipeline.", + max_score=6, + category="C", + rubric={ + 1: "No CI/CD", + 3: "Basic CI pipeline", + 5: "Good CI/CD setup", + 6: "Comprehensive DevOps with monitoring", + }, +) + +# Category D — Documentation (20 pts) +_D1 = BMADItem( + item_id="D1", + name="README Quality", + description="README completeness.", + max_score=6, + category="D", + rubric={ + 1: "No/minimal README", + 3: "Basic README", + 5: "Good README", + 6: "Exceptional README with all sections", + }, +) + +_D2 = BMADItem( + item_id="D2", + name="API Documentation", + description="API docs quality.", + max_score=5, + category="D", + rubric={ + 1: "No API docs", + 3: "Basic API docs", + 5: "Comprehensive API documentation", + }, +) + +_D3 = BMADItem( + item_id="D3", + name="Code Documentation", + description="In-code documentation.", + max_score=5, + category="D", + rubric={ + 1: "No code docs", + 3: "Basic comments", + 5: "Well-documented with docstrings", + }, +) + +_D4 = BMADItem( + item_id="D4", + name="Contributing Guide", + description="Contributor experience.", + max_score=4, + category="D", + rubric={ + 1: "No contributing guide", + 2: "Basic guide", + 3: "Good guide", + 4: "Comprehensive contributing guide", + }, +) + +BMAD_ITEMS: Dict[str, BMADItem] = { + "A1": _A1, + "A2": _A2, + "A3": _A3, + "A4": _A4, + "B1": _B1, + "B2": _B2, + "B3": _B3, + "B4": _B4, + "C1": _C1, + "C2": _C2, + "C3": _C3, + "C4": _C4, + "C5": _C5, + "D1": _D1, + "D2": _D2, + "D3": _D3, + "D4": _D4, +} + +BMAD_CATEGORIES: Dict[str, BMADCategory] = { + "A": BMADCategory( + category_id="A", + name="Problem Definition", + max_score=25, + items=["A1", "A2", "A3", "A4"], + ), + "B": BMADCategory( + category_id="B", + name="Technical Design", + max_score=25, + items=["B1", "B2", "B3", "B4"], + ), + "C": BMADCategory( + category_id="C", + name="Implementation", + max_score=30, + items=["C1", "C2", "C3", "C4", "C5"], + ), + "D": BMADCategory( + category_id="D", + name="Documentation", + max_score=20, + items=["D1", "D2", "D3", "D4"], + ), +} + + +def get_item(item_id: str) -> BMADItem: + """Get a BMAD item by ID. Raises KeyError if not found.""" + return BMAD_ITEMS[item_id] + + +def list_items() -> List[BMADItem]: + """List all 17 BMAD items in order (A1, A2, ..., D4).""" + return [BMAD_ITEMS[k] for k in sorted(BMAD_ITEMS.keys())] + + +def get_items_by_category(category: str) -> List[BMADItem]: + """Get all items in a category (A, B, C, or D).""" + return [item for item in BMAD_ITEMS.values() if item.category == category] + + +def get_category(category_id: str) -> BMADCategory: + """Get category by ID. Raises KeyError if not found.""" + return BMAD_CATEGORIES[category_id] + + +def get_max_total() -> int: + """Return the maximum total score (always 100).""" + return 100 + + +def get_category_max(category: str) -> int: + """Return max score for a category.""" + return BMAD_CATEGORIES[category].max_score diff --git a/backend/app/graph/graph_factory.py b/backend/app/graph/graph_factory.py index 22ae491..0138a54 100644 --- a/backend/app/graph/graph_factory.py +++ b/backend/app/graph/graph_factory.py @@ -1,10 +1,16 @@ -"""Graph Factory for selecting evaluation mode graphs.""" +"""Graph Factory for selecting evaluation mode graphs. + +This module provides graph builder registry and lookup functionality. +EvaluationMode enum is defined in app.models.graph to avoid circular imports. +""" -from enum import Enum from typing import Callable, Dict from langgraph.graph.state import CompiledStateGraph +# Re-export EvaluationMode from models for backward compatibility +from app.models.graph import EvaluationMode + __all__ = [ "EvaluationMode", "InvalidEvaluationModeError", @@ -14,11 +20,6 @@ ] -class EvaluationMode(str, Enum): - SIX_SOMMELIERS = "six_sommeliers" - GRAND_TASTING = "grand_tasting" - - class InvalidEvaluationModeError(Exception): def __init__(self, mode: str, available: list[str]): self.mode = mode diff --git a/backend/app/models/graph.py b/backend/app/models/graph.py index 2c2fdfa..b40c487 100644 --- a/backend/app/models/graph.py +++ b/backend/app/models/graph.py @@ -38,12 +38,17 @@ class EvaluationMode(str, Enum): """Canonical evaluation modes with machine IDs. + This is the single source of truth for evaluation modes. + Imported and re-exported by app.graph.graph_factory for backward compatibility. + Attributes: - SIX_HATS: Six Hats mode - 6 parallel agents, ~90s duration + SIX_SOMMELIERS: Six Sommeliers mode - 6 parallel agents, ~90s duration + GRAND_TASTING: Grand Tasting mode - comprehensive evaluation FULL_TECHNIQUES: Full Techniques mode - 75 techniques in 8 groups, ~3min duration """ - SIX_HATS = "six_hats" + SIX_SOMMELIERS = "six_sommeliers" + GRAND_TASTING = "grand_tasting" FULL_TECHNIQUES = "full_techniques" @@ -106,7 +111,7 @@ class ReactFlowGraph(BaseModel): Attributes: graph_schema_version: Schema version for backward compatibility (default: 2) - mode: Evaluation mode - "six_hats" | "full_techniques" + mode: Evaluation mode - "six_sommeliers" | "grand_tasting" | "full_techniques" nodes: List of ReactFlowNode objects edges: List of ReactFlowEdge objects description: Optional graph description @@ -123,7 +128,8 @@ class ReactFlowGraph(BaseModel): description="Schema version for backward compatibility and cache invalidation", ) mode: EvaluationMode = Field( - ..., description='Evaluation mode: "six_hats" | "full_techniques"' + ..., + description='Evaluation mode: "six_sommeliers" | "grand_tasting" | "full_techniques"', ) nodes: list[ReactFlowNode] = Field(..., description="List of graph nodes") edges: list[ReactFlowEdge] = Field(..., description="List of graph edges") @@ -200,7 +206,7 @@ class Graph3DNode(BaseModel): position: 3D coordinates color: Optional color for the node step_number: Animation step number for sequencing - hat_type: Optional hat type for Six Hats mode + hat_type: Optional hat type for Six Sommeliers mode technique_id: Optional technique identifier category: Optional category classification item_count: Optional count of items @@ -322,7 +328,7 @@ class Graph3DPayload(BaseModel): Attributes: graph_schema_version: Schema version for backward compatibility (default: 2) evaluation_id: Reference to the evaluation - mode: Evaluation mode - "six_hats" | "full_techniques" + mode: Evaluation mode - "six_sommeliers" | "grand_tasting" | "full_techniques" nodes: List of Graph3DNode objects edges: List of Graph3DEdge objects (bundled) edges_raw: Optional list of edges before bundling @@ -347,7 +353,7 @@ class Graph3DPayload(BaseModel): evaluation_id: str = Field(..., description="Reference to the evaluation") mode: str = Field( ..., - description="Evaluation mode (e.g., basic, hackathon, six_hats, full_techniques)", + description="Evaluation mode (e.g., six_sommeliers, grand_tasting, full_techniques)", ) nodes: list[Graph3DNode] = Field(..., description="List of graph nodes") edges: list[Graph3DEdge] = Field(..., description="List of graph edges (bundled)") @@ -539,7 +545,10 @@ class AgentContribution(BaseModel): class ModeResponse(BaseModel): """Response model for the evaluation mode endpoint.""" - mode: str = Field(..., description="Evaluation mode (six_hats or full_techniques)") + mode: str = Field( + ..., + description="Evaluation mode (six_sommeliers, grand_tasting, or full_techniques)", + ) evaluation_id: str = Field(..., description="The evaluation ID") diff --git a/backend/app/services/evaluation_service.py b/backend/app/services/evaluation_service.py index 581169d..3d2a9c5 100644 --- a/backend/app/services/evaluation_service.py +++ b/backend/app/services/evaluation_service.py @@ -18,11 +18,7 @@ from app.database.repositories.user import UserRepository from app.graph.state import EvaluationState from app.services.github_service import GitHubService, parse_github_url -from app.techniques import ( - determine_available_inputs, - filter_techniques, - load_techniques, -) +from app.techniques import load_techniques from app.providers.llm import resolve_byok from app.services.provider_routing import decide_provider @@ -52,9 +48,8 @@ async def _prepare_repo_context( techniques, technique_errors = load_techniques() if technique_errors: logger.warning("Technique load errors", extra={"errors": technique_errors}) - available_inputs = determine_available_inputs(repo_context) - filtered = filter_techniques(techniques, available_inputs) - repo_context["techniques"] = [tech.model_dump() for tech in filtered] + # Load all 75 techniques without source-based filtering + repo_context["techniques"] = [tech.model_dump() for tech in techniques] resolved_key, byok_error = resolve_byok(api_key) if byok_error: diff --git a/backend/app/services/graph_builder.py b/backend/app/services/graph_builder.py index 57572ab..78da343 100644 --- a/backend/app/services/graph_builder.py +++ b/backend/app/services/graph_builder.py @@ -4,11 +4,11 @@ structures for visualization of the evaluation pipeline. """ +from app.graph.graph_factory import EvaluationMode from app.models.graph import ( ReactFlowGraph, ReactFlowNode, ReactFlowEdge, - EvaluationMode, ) # Sommelier node configurations @@ -38,13 +38,13 @@ } -def build_six_hats_topology() -> ReactFlowGraph: - """Build ReactFlow graph for six_hats mode. +def build_six_sommeliers_topology() -> ReactFlowGraph: + """Build ReactFlow graph for six_sommeliers mode. Topology: Start -> 6 parallel agents -> Synthesis -> End Returns: - ReactFlowGraph with nodes and edges for the six_hats evaluation pipeline. + ReactFlowGraph with nodes and edges for the six_sommeliers evaluation pipeline. """ nodes: list[ReactFlowNode] = [] edges: list[ReactFlowEdge] = [] @@ -138,7 +138,7 @@ def build_six_hats_topology() -> ReactFlowGraph: ) return ReactFlowGraph( - mode=EvaluationMode.SIX_HATS.value, + mode=EvaluationMode.SIX_SOMMELIERS.value, nodes=nodes, edges=edges, description="Six sommeliers evaluate in parallel, then Jean-Pierre synthesizes", diff --git a/backend/app/techniques/__init__.py b/backend/app/techniques/__init__.py index f0ddfdd..5cb2d4a 100644 --- a/backend/app/techniques/__init__.py +++ b/backend/app/techniques/__init__.py @@ -1,7 +1,5 @@ from app.techniques.loader import ( DEFAULT_TECHNIQUES_DIR, - determine_available_inputs, - filter_techniques, load_techniques, ) from app.techniques.mappings import ( @@ -20,9 +18,11 @@ TechniqueNotFoundError, TechniqueRegistry, TechniqueValidationError, + get_all_techniques, get_registry, get_technique, get_techniques_by_category, + has_readme_content, list_available_categories, list_techniques, ) @@ -35,8 +35,7 @@ "TechniqueNotFoundError", "TechniqueRegistry", "TechniqueValidationError", - "determine_available_inputs", - "filter_techniques", + "get_all_techniques", "get_category_summary", "get_p0_techniques", "get_primary_technique", @@ -45,6 +44,7 @@ "get_technique_priority", "get_techniques_by_category", "get_techniques_for_category", + "has_readme_content", "list_all_mappings", "list_available_categories", "list_techniques", diff --git a/backend/app/techniques/definitions/aroma/5w1h.yaml b/backend/app/techniques/definitions/aroma/5w1h.yaml index 52e8ef6..a48459a 100644 --- a/backend/app/techniques/definitions/aroma/5w1h.yaml +++ b/backend/app/techniques/definitions/aroma/5w1h.yaml @@ -1,6 +1,5 @@ id: 5w1h name: 5W1H Analysis -nameKo: 5W1H 분석 category: aroma applicableHats: - white @@ -8,56 +7,54 @@ evaluationDimensions: - A1 - A2 - D1 -description: 'Who, What, When, Where, Why, How의 6가지 질문으로 +description: 'Technique to systematically analyze a problem or situation with 6 questions: Who, What, When, Where, Why, How. - 문제나 상황을 체계적으로 분석하는 기법. - - 기본적이지만 강력한 사실 파악 도구입니다. + Basic but powerful fact-finding tool. ' -promptTemplate: '## 5W1H 분석 +promptTemplate: '## 5W1H Analysis - 이 프로젝트가 기본적인 사실 파악을 완료했는지 분석하세요. + Analyze if the project has completed basic fact-finding. - ### 분석 관점: + ### Analysis Perspectives: - 1. **What**: 무엇을 만드는가? 핵심 기능은? + 1. **What**: What is being made? What is the core function? - 2. **Who**: 누구를 위한 것인가? 타겟 사용자는? + 2. **Who**: Who is it for? Who are the target users? - 3. **Why**: 왜 필요한가? 해결하려는 문제는? + 3. **Why**: Why is it needed? What problem does it solve? - 4. **When**: 언제 사용되는가? 사용 상황은? + 4. **When**: When is it used? usage situation? - 5. **Where**: 어디서 사용되는가? 환경은? + 5. **Where**: Where is it used? Environment? - 6. **How**: 어떻게 작동하는가? 방법은? + 6. **How**: How does it work? Method? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 6가지 질문 모두 명확하고 구체적으로 답변 + - 5 points: All 6 questions answered clearly and concretely - - 4점: 5가지 질문에 대한 명확한 답변 + - 4 points: Clear answers to 5 questions - - 3점: 4가지 질문에 대한 답변 + - 3 points: Answers to 4 questions - - 2점: 2-3가지 질문만 답변 + - 2 points: Answers to only 2-3 questions - - 1점: 기본적인 사실 파악도 불명확 + - 1 points: Basic fact-finding unclear ' scoring: min: 1 max: 5 criteria: - 5: 6가지 질문 모두 명확하고 구체적 - 4: 5가지 질문에 명확한 답변 - 3: 4가지 질문에 답변 - 2: 2-3가지 질문만 답변 - 1: 기본 사실 파악 불명확 + 5: All 6 questions clear and concrete + 4: 5 questions clear + 3: 4 questions answered + 2: 2-3 questions answered + 1: Basic facts unclear outputSchema: score: number what: string diff --git a/backend/app/techniques/definitions/aroma/assumption-reversal.yaml b/backend/app/techniques/definitions/aroma/assumption-reversal.yaml index c8a612b..d4eb810 100644 --- a/backend/app/techniques/definitions/aroma/assumption-reversal.yaml +++ b/backend/app/techniques/definitions/aroma/assumption-reversal.yaml @@ -1,6 +1,5 @@ id: assumption-reversal name: Assumption Reversal -nameKo: 가정 뒤집기 category: aroma applicableHats: - white @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - A1 - A3 -description: '숨겨진 가정을 찾아내고 +description: 'Technique to find hidden assumptions and reverse them. - 그 가정을 뒤집어 보는 기법. - - 당연하게 여기는 것들을 의심합니다. + Questions things taken for granted. ' -promptTemplate: '## Assumption Reversal 분석 +promptTemplate: '## Assumption Reversal Analysis - 이 프로젝트가 숨겨진 가정을 발견하고 도전했는지 분석하세요. + Analyze if the project discovered and challenged hidden assumptions. - ### 분석 관점: + ### Analysis Perspectives: - 1. **가정 발견**: 프로젝트의 숨겨진 가정을 식별했는가? + 1. **Assumption Discovery**: Have hidden assumptions of the project been identified? - 2. **가정 명시화**: 암묵적 가정을 명시적으로 표현했는가? + 2. **Assumption Explication**: Have implicit assumptions been expressed explicitly? - 3. **가정 검증**: 각 가정의 타당성을 검토했는가? + 3. **Assumption Verification**: Has the validity of each assumption been reviewed? - 4. **가정 도전**: 가정을 뒤집어 새로운 관점을 얻었는가? + 4. **Assumption Challenge**: Did reversing assumptions yield new perspectives? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 핵심 가정을 발견하고 뒤집어 새로운 통찰 획득 + - 5 points: Discovered core assumptions and gained new insights by reversing them - - 4점: 주요 가정을 식별하고 검증 + - 4 points: Identified and verified key assumptions - - 3점: 일부 가정을 인식 + - 3 points: Recognized some assumptions - - 2점: 가정을 거의 의식하지 않음 + - 2 points: Barely conscious of assumptions - - 1점: 가정에 대한 고려 없음 + - 1 points: No consideration of assumptions ' scoring: min: 1 max: 5 criteria: - 5: 핵심 가정 발견 및 역전으로 새 통찰 - 4: 주요 가정 식별 및 검증 - 3: 일부 가정 인식 - 2: 가정을 거의 의식 안 함 - 1: 가정 고려 없음 + 5: Core assumptions reversed, new insight + 4: Key assumptions identified/verified + 3: Some assumptions recognized + 2: Barely conscious + 1: No consideration outputSchema: score: number assumptionsFound: string[] diff --git a/backend/app/techniques/definitions/aroma/constraint-mapping.yaml b/backend/app/techniques/definitions/aroma/constraint-mapping.yaml index a16b75f..741a281 100644 --- a/backend/app/techniques/definitions/aroma/constraint-mapping.yaml +++ b/backend/app/techniques/definitions/aroma/constraint-mapping.yaml @@ -1,6 +1,5 @@ id: constraint-mapping name: Constraint Mapping -nameKo: 제약 조건 매핑 category: aroma applicableHats: - white @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - B3 - B4 -description: '프로젝트가 직면한 모든 제약 조건을 +description: 'Technique to systematically identify and categorize all constraints faced by the project. - 체계적으로 식별하고 분류하는 기법. - - 제약은 종종 혁신의 원천이 됩니다. + Constraints are often sources of innovation. ' -promptTemplate: '## Constraint Mapping 분석 +promptTemplate: '## Constraint Mapping Analysis - 이 프로젝트가 제약 조건을 명확히 파악했는지 분석하세요. + Analyze if the project clearly grasped constraint conditions. - ### 분석 관점: + ### Analysis Perspectives: - 1. **기술적 제약**: 기술적 한계를 인식하고 있는가? + 1. **Technical Constraints**: Are technical limitations recognized? - 2. **비즈니스 제약**: 시간, 비용, 자원 제약을 고려했는가? + 2. **Business Constraints**: Are time, cost, and resource constraints considered? - 3. **사용자 제약**: 사용자 환경의 제약을 파악했는가? + 3. **User Constraints**: Are user environment constraints identified? - 4. **규제 제약**: 법적, 규제적 제약을 고려했는가? + 4. **Regulatory Constraints**: Are legal and regulatory constraints considered? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 기술/비즈니스/사용자/규제 제약 모두 체계적으로 식별 + - 5 points: Systematically identified constraints in all 4 areas (Tech/Biz/User/Reg) - - 4점: 3개 영역의 제약 식별 + - 4 points: Identified constraints in 3 areas - - 3점: 2개 영역의 제약 식별 + - 3 points: Identified constraints in 2 areas - - 2점: 1개 영역의 제약만 인식 + - 2 points: Recognized constraints in only 1 area - - 1점: 제약 분석 없음 + - 1 points: No constraint analysis ' scoring: min: 1 max: 5 criteria: - 5: 4개 영역 제약 모두 체계적 식별 - 4: 3개 영역 제약 식별 - 3: 2개 영역 제약 식별 - 2: 1개 영역 제약만 인식 - 1: 제약 분석 없음 + 5: Systematic ID of 4 areas + 4: ID of 3 areas + 3: ID of 2 areas + 2: ID of 1 area + 1: No analysis outputSchema: score: number technicalConstraints: string[] diff --git a/backend/app/techniques/definitions/aroma/data-mining.yaml b/backend/app/techniques/definitions/aroma/data-mining.yaml index 7379360..4b54478 100644 --- a/backend/app/techniques/definitions/aroma/data-mining.yaml +++ b/backend/app/techniques/definitions/aroma/data-mining.yaml @@ -1,6 +1,5 @@ id: data-mining name: Data Mining -nameKo: 데이터 마이닝 관점 category: aroma applicableHats: - white @@ -8,52 +7,50 @@ evaluationDimensions: - A1 - A4 - B1 -description: '데이터에서 패턴과 인사이트를 추출하는 기법. +description: 'Technique to extract patterns and insights from data. - 프로젝트가 데이터 기반 의사결정을 - - 하고 있는지 평가합니다. + Evaluates if the project is making data-driven decisions. ' -promptTemplate: '## Data Mining 분석 +promptTemplate: '## Data Mining Analysis - 이 프로젝트가 데이터 기반으로 의사결정을 했는지 분석하세요. + Analyze if the project made decisions based on data. - ### 분석 관점: + ### Analysis Perspectives: - 1. **데이터 수집**: 관련 데이터를 수집했는가? + 1. **Data Collection**: Was relevant data collected? - 2. **데이터 분석**: 데이터에서 패턴을 발견했는가? + 2. **Data Analysis**: Were patterns discovered in the data? - 3. **인사이트 도출**: 분석에서 의미 있는 통찰을 얻었는가? + 3. **Insight Derivation**: Were meaningful insights gained from analysis? - 4. **의사결정 반영**: 인사이트가 설계에 반영되었는가? + 4. **Decision Reflection**: Were insights reflected in the design? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 데이터 분석으로 핵심 인사이트 도출 및 적용 + - 5 points: Systematic data analysis leading to core insights and application - - 4점: 데이터 분석이 설계에 반영됨 + - 4 points: Data analysis reflected in design - - 3점: 일부 데이터 참조 + - 3 points: Some data referenced - - 2점: 피상적 데이터 언급 + - 2 points: Superficial mention of data - - 1점: 데이터 기반 의사결정 없음 + - 1 points: No data-driven decision making ' scoring: min: 1 max: 5 criteria: - 5: 체계적 분석으로 인사이트 도출 및 적용 - 4: 데이터 분석이 설계에 반영 - 3: 일부 데이터 참조 - 2: 피상적 데이터 언급 - 1: 데이터 기반 의사결정 없음 + 5: Systematic analysis, insight application + 4: Analysis reflected in design + 3: Some data referenced + 2: Superficial data mention + 1: No data-driven decision outputSchema: score: number dataCollected: string[] diff --git a/backend/app/techniques/definitions/aroma/fact-checking.yaml b/backend/app/techniques/definitions/aroma/fact-checking.yaml index 493cedd..afb46f8 100644 --- a/backend/app/techniques/definitions/aroma/fact-checking.yaml +++ b/backend/app/techniques/definitions/aroma/fact-checking.yaml @@ -1,6 +1,5 @@ id: fact-checking name: Fact Checking -nameKo: 팩트 체킹 category: aroma applicableHats: - white @@ -8,52 +7,52 @@ evaluationDimensions: - A1 - A2 - D1 -description: '프로젝트에서 주장하는 사실, 통계, 데이터의 정확성과 +description: 'Technique to verify the accuracy and reliability of facts, statistics, and data claimed in the project. - 신뢰성을 검증하는 기법. 객관적 증거 기반 평가. + Objective evidence-based evaluation. ' -promptTemplate: '## Fact Checking (사실 검증) +promptTemplate: '## Fact Checking Analysis - 이 프로젝트에서 주장하는 사실들이 정확하고 신뢰할 수 있는지 검증하세요. + Verify if the facts claimed in this project are accurate and reliable. - ### 검증 관점: + ### Verification Perspectives: - 1. **통계/수치 정확성**: 인용된 통계나 수치가 정확한가? + 1. **Statistics/Numerical Accuracy**: Are quoted statistics or numbers accurate? - 2. **출처 명시**: 주장의 근거가 명확히 제시되었는가? + 2. **Source Specification**: Is the basis of the claim clearly presented? - 3. **논리적 일관성**: 주장들 사이에 모순이 없는가? + 3. **Logical Consistency**: Are there no contradictions between claims? - 4. **과장 여부**: 과장되거나 오해의 소지가 있는 표현은 없는가? + 4. **Exaggeration Check**: Are there exaggerated or misleading expressions? - 5. **검증 가능성**: 주장들을 독립적으로 검증할 수 있는가? + 5. **Verifiability**: Can the claims be independently verified? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 모든 주장이 출처와 함께 정확하게 제시됨 + - 5 points: All claims presented accurately with sources - - 4점: 대부분 정확, 일부 출처 누락 + - 4 points: Mostly accurate, some sources missing - - 3점: 기본적으로 정확하나 검증이 어려운 부분 있음 + - 3 points: Basically accurate but difficult to verify some parts - - 2점: 일부 부정확하거나 과장된 주장 있음 + - 2 points: Some inaccurate or exaggerated claims - - 1점: 주장의 근거가 불분명하거나 부정확함 + - 1 points: Basis of claims unclear or inaccurate ' scoring: min: 1 max: 5 criteria: - 5: 모든 주장 정확, 출처 명시 - 4: 대부분 정확, 일부 출처 누락 - 3: 기본적 정확, 검증 어려움 - 2: 일부 부정확/과장 - 1: 근거 불분명/부정확 + 5: All claims accurate, sources cited + 4: Mostly accurate, some sources missing + 3: Basically accurate, verification hard + 2: Some inaccurate/exaggerated + 1: Basis unclear/inaccurate outputSchema: score: number statisticsAccuracy: string diff --git a/backend/app/techniques/definitions/aroma/failure-analysis.yaml b/backend/app/techniques/definitions/aroma/failure-analysis.yaml index 0cf2378..6c3e9df 100644 --- a/backend/app/techniques/definitions/aroma/failure-analysis.yaml +++ b/backend/app/techniques/definitions/aroma/failure-analysis.yaml @@ -1,6 +1,5 @@ id: failure-analysis name: Failure Analysis (FMEA) -nameKo: 실패 분석 category: aroma applicableHats: - black @@ -11,50 +10,48 @@ evaluationDimensions: - C3 description: 'Failure Mode and Effects Analysis (FMEA). - 잠재적 실패 모드를 사전에 식별하고 - - 그 영향과 대응책을 분석합니다. + Identifies potential failure modes in advance and analyzes their impact and countermeasures. ' -promptTemplate: '## Failure Analysis (FMEA) 분석 +promptTemplate: '## Failure Analysis (FMEA) - 이 프로젝트가 잠재적 실패 모드를 고려했는지 분석하세요. + Analyze if the project considered potential failure modes. - ### 분석 관점: + ### Analysis Perspectives: - 1. **실패 모드 식별**: 어떤 방식으로 실패할 수 있는지 식별했는가? + 1. **Failure Mode Identification**: Identified how it could fail? - 2. **영향 분석**: 각 실패의 영향도를 평가했는가? + 2. **Impact Analysis**: Evaluated the impact of each failure? - 3. **발생 가능성**: 실패 발생 확률을 고려했는가? + 3. **Occurrence Probability**: Considered probability of failure? - 4. **대응책**: 각 실패에 대한 대응책이 있는가? + 4. **Countermeasures**: Are there countermeasures for each failure? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 FMEA 수행, 우선순위화된 대응책 존재 + - 5 points: Systematic FMEA performed, prioritized countermeasures exist - - 4점: 주요 실패 모드 식별 및 대응 + - 4 points: Key failure modes identified and addressed - - 3점: 일부 위험 인식 + - 3 points: Some risks recognized - - 2점: 피상적 위험 언급 + - 2 points: Superficial risk mention - - 1점: 위험 분석 없음 + - 1 points: No risk analysis ' scoring: min: 1 max: 5 criteria: - 5: 체계적 FMEA, 우선순위화된 대응책 - 4: 주요 실패 모드 식별 및 대응 - 3: 일부 위험 인식 - 2: 피상적 위험 언급 - 1: 위험 분석 없음 + 5: Systematic FMEA, prioritized countermeasures + 4: Key failure modes identified + 3: Some risks recognized + 2: Superficial risk mention + 1: No risk analysis outputSchema: score: number failureModes: string[] diff --git a/backend/app/techniques/definitions/aroma/five-whys.yaml b/backend/app/techniques/definitions/aroma/five-whys.yaml index 71b4c68..a302795 100644 --- a/backend/app/techniques/definitions/aroma/five-whys.yaml +++ b/backend/app/techniques/definitions/aroma/five-whys.yaml @@ -1,6 +1,5 @@ id: five-whys name: Five Whys -nameKo: 5 Whys category: aroma applicableHats: - white @@ -9,52 +8,50 @@ evaluationDimensions: - A1 - A2 - B4 -description: '토요타에서 개발한 근본 원인 분석 기법. +description: 'Root cause analysis technique developed by Toyota. - "왜?"를 5번 반복하여 표면적 증상이 아닌 - - 근본 원인을 찾아냅니다. + Finds the root cause, not superficial symptoms, by repeating "Why?" 5 times. ' -promptTemplate: '## Five Whys 분석 +promptTemplate: '## Five Whys Analysis - 이 프로젝트의 문제 정의가 근본 원인까지 파고들었는지 분석하세요. + Analyze if the project''s problem definition dug down to the root cause. - ### 분석 관점: + ### Analysis Perspectives: - 1. **분석 깊이**: "왜?"를 몇 단계까지 질문했는가? + 1. **Analysis Depth**: How many levels deep was "Why?" asked? - 2. **표면 vs 근본**: 표면적 증상과 근본 원인을 구분했는가? + 2. **Surface vs Root**: Did it distinguish between superficial symptoms and root causes? - 3. **인과관계**: 원인과 결과의 연결이 논리적인가? + 3. **Causality**: Is the connection between cause and effect logical? - 4. **누락된 질문**: 더 깊이 파고들 수 있는 부분이 있는가? + 4. **Missing Questions**: Are there parts that can be dug deeper? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5단계 이상 분석으로 진정한 근본 원인 도달 + - 5 points: Reached true root cause with 5+ levels of analysis - - 4점: 4단계 분석으로 핵심 원인 파악 + - 4 points: Identified core cause with 4 levels of analysis - - 3점: 3단계 분석 + - 3 points: 3 levels of analysis - - 2점: 2단계 분석 + - 2 points: 2 levels of analysis - - 1점: 표면적 증상만 다룸 + - 1 points: Covered only superficial symptoms ' scoring: min: 1 max: 5 criteria: - 5: 5단계+ 분석으로 근본 원인 도달 - 4: 4단계 분석으로 핵심 원인 파악 - 3: 3단계 분석 - 2: 2단계 분석 - 1: 표면적 증상만 다룸 + 5: 5+ levels, reached root cause + 4: 4 levels, core cause identified + 3: 3 levels analysis + 2: 2 levels analysis + 1: Superficial symptoms only outputSchema: score: number whyChain: string[] diff --git a/backend/app/techniques/definitions/aroma/mind-mapping.yaml b/backend/app/techniques/definitions/aroma/mind-mapping.yaml index 1ce1ad2..d906667 100644 --- a/backend/app/techniques/definitions/aroma/mind-mapping.yaml +++ b/backend/app/techniques/definitions/aroma/mind-mapping.yaml @@ -1,6 +1,5 @@ id: mind-mapping name: Mind Mapping -nameKo: 마인드 매핑 category: aroma applicableHats: - white @@ -9,52 +8,50 @@ evaluationDimensions: - A1 - B2 - D1 -description: 'Tony Buzan이 개발한 시각적 사고 도구. +description: 'Visual thinking tool developed by Tony Buzan. - 중심 주제에서 방사형으로 아이디어를 확장하여 - - 개념들 간의 관계를 시각화합니다. + Expands ideas radially from a central theme to visualize relationships between concepts. ' -promptTemplate: '## Mind Mapping 분석 +promptTemplate: '## Mind Mapping Analysis - 이 프로젝트가 아이디어를 체계적으로 구조화했는지 분석하세요. + Analyze if the project structured ideas systematically. - ### 분석 관점: + ### Analysis Perspectives: - 1. **중심 주제**: 핵심 개념이 명확히 정의되었는가? + 1. **Central Theme**: Is the core concept clearly defined? - 2. **가지 확장**: 관련 개념들이 논리적으로 연결되었는가? + 2. **Branch Expansion**: Are related concepts logically connected? - 3. **계층 구조**: 주제와 하위 주제의 계층이 명확한가? + 3. **Hierarchy**: Is the hierarchy of theme and sub-themes clear? - 4. **연결성**: 서로 다른 가지들 간의 관계가 표현되었는가? + 4. **Connectivity**: Are relationships between different branches expressed? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적인 개념 구조와 명확한 관계 표현 + - 5 points: Systematic concept structure and clear relationship expression - - 4점: 잘 조직된 계층 구조 + - 4 points: Well-organized hierarchy - - 3점: 기본적인 구조화 + - 3 points: Basic structuring - - 2점: 구조가 불명확 + - 2 points: Structure unclear - - 1점: 아이디어가 산발적으로 나열 + - 1 points: Ideas listed sporadically ' scoring: min: 1 max: 5 criteria: - 5: 체계적 개념 구조와 명확한 관계 - 4: 잘 조직된 계층 구조 - 3: 기본적 구조화 - 2: 구조 불명확 - 1: 아이디어 산발적 나열 + 5: Systematic structure, clear relationships + 4: Well-organized hierarchy + 3: Basic structuring + 2: Structure unclear + 1: Sporadic listing outputSchema: score: number centralConcept: string diff --git a/backend/app/techniques/definitions/aroma/morphological-analysis.yaml b/backend/app/techniques/definitions/aroma/morphological-analysis.yaml index 2cadf72..8adb5ec 100644 --- a/backend/app/techniques/definitions/aroma/morphological-analysis.yaml +++ b/backend/app/techniques/definitions/aroma/morphological-analysis.yaml @@ -1,6 +1,5 @@ id: morphological-analysis name: Morphological Analysis -nameKo: 형태학적 분석 category: aroma applicableHats: - white @@ -8,52 +7,50 @@ evaluationDimensions: - A1 - B2 - B3 -description: 'Fritz Zwicky가 개발한 체계적 문제 분석 기법. +description: 'Systematic problem analysis technique developed by Fritz Zwicky. - 문제의 모든 차원과 가능한 값들을 나열하고 - - 조합을 탐색하여 해결책을 찾습니다. + Lists all dimensions of a problem and possible values, then explores combinations to find solutions. ' -promptTemplate: '## Morphological Analysis 분석 +promptTemplate: '## Morphological Analysis - 이 프로젝트가 문제의 모든 차원을 체계적으로 탐색했는지 분석하세요. + Analyze if the project systematically explored all dimensions of the problem. - ### 분석 관점: + ### Analysis Perspectives: - 1. **차원 식별**: 문제의 핵심 파라미터들을 식별했는가? + 1. **Dimension Identification**: Identified key parameters of the problem? - 2. **값 탐색**: 각 파라미터의 가능한 값들을 열거했는가? + 2. **Value Exploration**: Listed possible values for each parameter? - 3. **조합 분석**: 파라미터 조합을 체계적으로 탐색했는가? + 3. **Combination Analysis**: Systematically explored parameter combinations? - 4. **커버리지**: 가능한 해결 공간을 충분히 탐색했는가? + 4. **Coverage**: Sufficiently explored the possible solution space? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 모든 핵심 파라미터 × 값 조합을 체계적으로 탐색 + - 5 points: Systematically explored all key parameter x value combinations - - 4점: 대부분의 파라미터를 고려 + - 4 points: Considered most parameters - - 3점: 주요 파라미터 식별 + - 3 points: Identified key parameters - - 2점: 일부 차원만 고려 + - 2 points: Considered only some dimensions - - 1점: 단일 차원 접근 + - 1 points: Single dimension approach ' scoring: min: 1 max: 5 criteria: - 5: 모든 파라미터 × 값 조합 체계적 탐색 - 4: 대부분의 파라미터 고려 - 3: 주요 파라미터 식별 - 2: 일부 차원만 고려 - 1: 단일 차원 접근 + 5: Systematic exploration of all combinations + 4: Considered most parameters + 3: Identified key parameters + 2: Considered some dimensions + 1: Single dimension approach outputSchema: score: number parametersIdentified: string[] diff --git a/backend/app/techniques/definitions/aroma/pestle-analysis.yaml b/backend/app/techniques/definitions/aroma/pestle-analysis.yaml index f267bbe..2eb0bba 100644 --- a/backend/app/techniques/definitions/aroma/pestle-analysis.yaml +++ b/backend/app/techniques/definitions/aroma/pestle-analysis.yaml @@ -1,6 +1,5 @@ id: pestle-analysis name: PESTLE Analysis -nameKo: PESTLE 분석 category: aroma applicableHats: - white @@ -9,56 +8,54 @@ evaluationDimensions: - A1 - A4 - B4 -description: 'Francis Aguilar(Harvard Business School)가 개발한 거시환경 분석 프레임워크. +description: 'Macro-environmental analysis framework developed by Francis Aguilar (Harvard Business School). - Political(정치), Economic(경제), Social(사회), Technological(기술), - - Legal(법률), Environmental(환경) 6가지 요인으로 외부 환경을 체계적으로 분석. + Systematically analyzes external environment with 6 factors: Political, Economic, Social, Technological, Legal, Environmental. ' -promptTemplate: '## PESTLE 분석 +promptTemplate: '## PESTLE Analysis - 이 프로젝트가 PESTLE 6가지 환경 요인을 분석했는지 평가하세요. + Evaluate if the project analyzed the 6 PESTLE environmental factors. - ### PESTLE 6가지 요인: + ### PESTLE 6 Factors: - 1. **Political (정치)**: 정책, 규제, 정치적 안정성 고려? + 1. **Political**: Policy, regulation, political stability considered? - 2. **Economic (경제)**: 경제 상황, 시장 동향, 환율 등 분석? + 2. **Economic**: Economic situation, market trends, exchange rates analyzed? - 3. **Social (사회)**: 인구통계, 문화, 라이프스타일 변화 고려? + 3. **Social**: Demographics, culture, lifestyle changes considered? - 4. **Technological (기술)**: 기술 트렌드, R&D, 자동화 영향 분석? + 4. **Technological**: Tech trends, R&D, automation impact analyzed? - 5. **Legal (법률)**: 법적 요구사항, 규제 준수, 지적재산권? + 5. **Legal**: Legal requirements, compliance, IP? - 6. **Environmental (환경)**: 환경 규제, 지속가능성, 기후 영향? + 6. **Environmental**: Environmental regulations, sustainability, climate impact? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 6가지 요인 모두 심층 분석, 상호작용 고려 + - 5 points: In-depth analysis of all 6 factors, interactions considered - - 4점: 5-6가지 요인 분석, 핵심 영향 식별 + - 4 points: Analysis of 5-6 factors, key impacts identified - - 3점: 3-4가지 요인 분석 + - 3 points: Analysis of 3-4 factors - - 2점: 1-2가지 요인만 언급 + - 2 points: Mentioned only 1-2 factors - - 1점: 거시환경 분석 없음 + - 1 points: No macro-environmental analysis ' scoring: min: 1 max: 5 criteria: - 5: 6가지 심층 분석, 상호작용 고려 - 4: 5-6가지 분석, 핵심 영향 식별 - 3: 3-4가지 요인 분석 - 2: 1-2가지 요인만 언급 - 1: 거시환경 분석 없음 + 5: Deep analysis of 6 factors, interactions + 4: 5-6 factors, key impacts identified + 3: 3-4 factors analyzed + 2: 1-2 factors mentioned + 1: No macro analysis outputSchema: score: number politicalFactors: string @@ -74,5 +71,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Francis Aguilar, Harvard Business School (1967) - academicReference: 전략기획 표준 도구, 글로벌 MBA 커리큘럼 + academicReference: Standard tool for strategic planning, Global MBA curriculum requiredSources: either diff --git a/backend/app/techniques/definitions/aroma/question-storming.yaml b/backend/app/techniques/definitions/aroma/question-storming.yaml index ae71538..e0ae0f7 100644 --- a/backend/app/techniques/definitions/aroma/question-storming.yaml +++ b/backend/app/techniques/definitions/aroma/question-storming.yaml @@ -1,6 +1,5 @@ id: question-storming name: Question Storming -nameKo: 질문 스토밍 category: aroma applicableHats: - white @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - A1 - A2 -description: '답을 찾기 전에 좋은 질문을 먼저 찾는 기법. +description: 'Technique to find good questions before finding answers. - "올바른 질문이 올바른 답을 이끈다"는 - - 원리에 기반합니다. + Based on the principle that "the right question leads to the right answer". ' -promptTemplate: '## Question Storming 분석 +promptTemplate: '## Question Storming Analysis - 이 프로젝트가 좋은 질문을 던지고 있는지 분석하세요. + Analyze if the project is asking good questions. - ### 분석 관점: + ### Analysis Perspectives: - 1. **질문의 질**: 프로젝트가 던지는 질문이 통찰력 있는가? + 1. **Question Quality**: Are the questions insightful? - 2. **질문의 다양성**: 다양한 관점의 질문이 있는가? + 2. **Question Diversity**: Are there questions from various perspectives? - 3. **질문의 깊이**: 표면적 질문을 넘어 깊은 질문이 있는가? + 3. **Question Depth**: Are there deep questions beyond surface ones? - 4. **미답 질문**: 아직 답하지 못한 중요한 질문을 인식하고 있는가? + 4. **Unanswered Questions**: Does it recognize important unanswered questions? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 통찰력 있는 질문들로 문제의 본질을 파악 + - 5 points: Insightful questions grasping the essence of the problem - - 4점: 다양하고 깊이 있는 질문들 + - 4 points: Diverse and in-depth questions - - 3점: 적절한 질문들이 있음 + - 3 points: Appropriate questions exist - - 2점: 질문이 피상적 + - 2 points: Questions are superficial - - 1점: 질문 없이 바로 해결책으로 직행 + - 1 points: Proceeded to solution without questions ' scoring: min: 1 max: 5 criteria: - 5: 통찰력 있는 질문으로 본질 파악 - 4: 다양하고 깊이 있는 질문 - 3: 적절한 질문들 - 2: 피상적 질문 - 1: 질문 없이 해결책 직행 + 5: Insightful questions, grasping essence + 4: Diverse and deep questions + 3: Appropriate questions + 2: Superficial questions + 1: No questions outputSchema: score: number keyQuestions: string[] diff --git a/backend/app/techniques/definitions/balance/chaos-engineering.yaml b/backend/app/techniques/definitions/balance/chaos-engineering.yaml index 3e8e37d..ccff6d9 100644 --- a/backend/app/techniques/definitions/balance/chaos-engineering.yaml +++ b/backend/app/techniques/definitions/balance/chaos-engineering.yaml @@ -1,6 +1,5 @@ id: chaos-engineering name: Chaos Engineering -nameKo: 카오스 엔지니어링 사고 category: balance applicableHats: - black @@ -9,52 +8,50 @@ evaluationDimensions: - B2 - B3 - B4 -description: '의도적으로 시스템에 장애를 주입하여 +description: 'A technique to test resilience and stability by intentionally injecting failures into the system. - 복원력과 안정성을 테스트하는 기법. - - Netflix가 개발한 시스템 신뢰성 검증 방법론입니다. + Methodology for validating system reliability developed by Netflix. ' -promptTemplate: '## Chaos Engineering 분석 +promptTemplate: '## Chaos Engineering Analysis - 프로젝트가 시스템 복원력을 어떻게 고려했는지 분석하세요. + Analyze how the project has considered system resilience. - ### 분석 관점: + ### Analysis Perspectives: - 1. **장애 시나리오**: 가능한 장애 상황을 식별했는가? + 1. **Failure Scenarios**: Have potential failure situations been identified? - 2. **복원 전략**: 각 장애에 대한 복구 방안이 있는가? + 2. **Recovery Strategies**: Are there recovery plans for each failure? - 3. **테스트 계획**: 장애 대응을 테스트할 계획이 있는가? + 3. **Testing Plan**: Is there a plan to test failure responses? - 4. **모니터링**: 시스템 상태 모니터링 방안이 있는가? + 4. **Monitoring**: Is there a way to monitor system health? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 장애 시나리오, 복원 전략, 테스트 계획 수립 + - 5 points: Systematic failure scenarios, recovery strategies, and test plans established - - 4점: 주요 장애 대응 계획 존재 + - 4 points: Major failure response plans exist - - 3점: 일부 장애 상황 고려 + - 3 points: Some failure situations considered - - 2점: 장애 대응 불명확 + - 2 points: Failure response unclear - - 1점: 장애/복원 고려 없음 + - 1 points: No consideration of failure/recovery ' scoring: min: 1 max: 5 criteria: - 5: 체계적 장애/복원/테스트 계획 - 4: 주요 장애 대응 존재 - 3: 일부 장애 고려 - 2: 대응 불명확 - 1: 장애 고려 없음 + 5: Systematic failure/recovery/test plans + 4: Major failure responses exist + 3: Some failures considered + 2: Response unclear + 1: No failure consideration outputSchema: score: number failureScenarios: string[] diff --git a/backend/app/techniques/definitions/balance/decision-tree-mapping.yaml b/backend/app/techniques/definitions/balance/decision-tree-mapping.yaml index 34f4912..733d5f4 100644 --- a/backend/app/techniques/definitions/balance/decision-tree-mapping.yaml +++ b/backend/app/techniques/definitions/balance/decision-tree-mapping.yaml @@ -1,6 +1,5 @@ id: decision-tree-mapping name: Decision Tree Mapping -nameKo: 의사결정 트리 매핑 category: balance applicableHats: - white @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - B2 - B3 -description: '의사결정 포인트와 분기점을 시각화하는 기법. +description: 'A technique to visualize decision points and branches. - 각 선택지의 결과와 영향을 체계적으로 분석하여 - - 최적의 의사결정 경로를 찾습니다. + Systematically analyzes the consequences and impacts of each option to find the optimal decision path. ' -promptTemplate: '## Decision Tree Mapping 분석 +promptTemplate: '## Decision Tree Mapping Analysis - 프로젝트가 의사결정 과정을 체계적으로 분석했는지 평가하세요. + Evaluate if the project has systematically analyzed the decision-making process. - ### 분석 관점: + ### Analysis Perspectives: - 1. **결정 포인트**: 주요 의사결정 지점을 식별했는가? + 1. **Decision Points**: Have key decision points been identified? - 2. **선택지 분석**: 각 결정의 대안을 분석했는가? + 2. **Alternative Analysis**: Have alternatives for each decision been analyzed? - 3. **결과 예측**: 각 선택의 결과를 예측했는가? + 3. **Outcome Prediction**: Have the consequences of each choice been predicted? - 4. **최적 경로**: 최선의 의사결정 경로를 도출했는가? + 4. **Optimal Path**: Has the best decision path been derived? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 의사결정 트리, 정량적 분석 포함 + - 5 points: Systematic decision tree with quantitative analysis - - 4점: 주요 결정 포인트와 대안 분석 + - 4 points: Analysis of key decision points and alternatives - - 3점: 일부 의사결정 분석 + - 3 points: Some decision analysis - - 2점: 의사결정 과정 불명확 + - 2 points: Decision process unclear - - 1점: 의사결정 분석 없음 + - 1 points: No decision analysis ' scoring: min: 1 max: 5 criteria: - 5: 체계적 트리, 정량적 분석 - 4: 주요 결정 포인트 분석 - 3: 일부 의사결정 분석 - 2: 과정 불명확 - 1: 분석 없음 + 5: Systematic tree, quantitative analysis + 4: Key decision points analyzed + 3: Some decision analysis + 2: Process unclear + 1: No analysis outputSchema: score: number decisionPoints: string[] diff --git a/backend/app/techniques/definitions/balance/ecosystem-thinking.yaml b/backend/app/techniques/definitions/balance/ecosystem-thinking.yaml index b6747e5..a018afb 100644 --- a/backend/app/techniques/definitions/balance/ecosystem-thinking.yaml +++ b/backend/app/techniques/definitions/balance/ecosystem-thinking.yaml @@ -1,6 +1,5 @@ id: ecosystem-thinking name: Ecosystem Thinking -nameKo: 생태계적 사고 category: balance applicableHats: - blue @@ -9,52 +8,50 @@ evaluationDimensions: - A2 - B1 - D1 -description: '제품/서비스를 독립적으로 보지 않고 +description: 'A technique to view a product/service not independently but within a broader ecosystem context. - 더 넓은 생태계 맥락에서 바라보는 기법. - - 이해관계자, 경쟁자, 보완재를 종합적으로 고려합니다. + Comprehensively considers stakeholders, competitors, and complementors. ' -promptTemplate: '## Ecosystem Thinking 분석 +promptTemplate: '## Ecosystem Thinking Analysis - 프로젝트가 생태계 맥락을 얼마나 잘 이해했는지 분석하세요. + Analyze how well the project understands the ecosystem context. - ### 분석 관점: + ### Analysis Perspectives: - 1. **생태계 매핑**: 관련 이해관계자를 식별했는가? + 1. **Ecosystem Mapping**: Have relevant stakeholders been identified? - 2. **상호작용**: 각 요소 간의 관계를 이해했는가? + 2. **Interactions**: Are relationships between elements understood? - 3. **포지셔닝**: 생태계 내 위치를 명확히 했는가? + 3. **Positioning**: Is the position within the ecosystem clear? - 4. **시너지**: 생태계를 활용한 성장 전략이 있는가? + 4. **Synergy**: Is there a growth strategy leveraging the ecosystem? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전한 생태계 맵, 전략적 포지셔닝 + - 5 points: Complete ecosystem map, strategic positioning - - 4점: 주요 이해관계자 및 관계 파악 + - 4 points: Key stakeholders and relationships identified - - 3점: 일부 생태계 요소 고려 + - 3 points: Some ecosystem elements considered - - 2점: 생태계 시각 부족 + - 2 points: Lack of ecosystem perspective - - 1점: 생태계 고려 없음 + - 1 points: No ecosystem consideration ' scoring: min: 1 max: 5 criteria: - 5: 완전한 생태계 맵, 전략적 포지셔닝 - 4: 주요 이해관계자 파악 - 3: 일부 생태계 요소 - 2: 시각 부족 - 1: 생태계 무고려 + 5: Complete ecosystem map, strategic positioning + 4: Key stakeholders identified + 3: Some ecosystem elements + 2: Lack of perspective + 1: No ecosystem consideration outputSchema: score: number stakeholders: string[] diff --git a/backend/app/techniques/definitions/balance/evolutionary-pressure.yaml b/backend/app/techniques/definitions/balance/evolutionary-pressure.yaml index a7ad4ef..ac91ff3 100644 --- a/backend/app/techniques/definitions/balance/evolutionary-pressure.yaml +++ b/backend/app/techniques/definitions/balance/evolutionary-pressure.yaml @@ -1,6 +1,5 @@ id: evolutionary-pressure name: Evolutionary Pressure Analysis -nameKo: 진화적 압력 category: balance applicableHats: - black @@ -9,52 +8,50 @@ evaluationDimensions: - A2 - B3 - D1 -description: '시장과 환경의 진화적 압력을 분석하여 +description: 'A technique to assess long-term viability by analyzing evolutionary pressures from the market and environment. - 장기적 생존 가능성을 평가하는 기법. - - 적응력과 변화 대응 능력을 검토합니다. + Examines adaptability and ability to respond to change. ' -promptTemplate: '## Evolutionary Pressure Analysis 분석 +promptTemplate: '## Evolutionary Pressure Analysis - 프로젝트가 환경 변화에 대한 적응력을 갖추었는지 분석하세요. + Analyze if the project has adaptability to environmental changes. - ### 분석 관점: + ### Analysis Perspectives: - 1. **환경 변화**: 시장/기술 환경의 변화 트렌드를 파악했는가? + 1. **Environmental Change**: Have trends in market/technology changes been identified? - 2. **적응 전략**: 변화에 대응할 전략이 있는가? + 2. **Adaptation Strategy**: Is there a strategy to respond to changes? - 3. **유연성**: 피벗이나 조정이 가능한 구조인가? + 3. **Flexibility**: Is the structure capable of pivoting or adjusting? - 4. **장기 생존**: 장기적 생존 가능성을 고려했는가? + 4. **Long-term Survival**: Has long-term viability been considered? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 트렌드 예측, 유연한 적응 전략, 장기 비전 + - 5 points: Trend prediction, flexible adaptation strategy, long-term vision - - 4점: 환경 변화 인식 및 대응 계획 + - 4 points: Environmental change recognition and response plan - - 3점: 일부 변화 요소 고려 + - 3 points: Some change factors considered - - 2점: 현재 상황에만 집중 + - 2 points: Focused only on current situation - - 1점: 환경 변화 무시 + - 1 points: Environmental changes ignored ' scoring: min: 1 max: 5 criteria: - 5: 트렌드 예측, 유연한 적응, 장기 비전 - 4: 변화 인식 및 대응 - 3: 일부 변화 고려 - 2: 현재만 집중 - 1: 변화 무시 + 5: Trend prediction, flexible adaptation, long-term vision + 4: Change recognition and response + 3: Some changes considered + 2: Focused on current only + 1: Changes ignored outputSchema: score: number environmentalChanges: string[] diff --git a/backend/app/techniques/definitions/balance/porters-five-forces.yaml b/backend/app/techniques/definitions/balance/porters-five-forces.yaml index 0495449..b8a82a0 100644 --- a/backend/app/techniques/definitions/balance/porters-five-forces.yaml +++ b/backend/app/techniques/definitions/balance/porters-five-forces.yaml @@ -1,6 +1,5 @@ id: porters-five-forces name: Porter's Five Forces -nameKo: 포터의 5가지 경쟁요인 category: balance applicableHats: - white @@ -10,54 +9,52 @@ evaluationDimensions: - A4 - B3 - B4 -description: 'Michael Porter(Harvard Business School, 1979)가 개발한 산업 경쟁 분석 프레임워크. +description: 'Industry competition analysis framework developed by Michael Porter (Harvard Business School, 1979). - 5가지 경쟁 요인(기존 경쟁자, 잠재적 진입자, 대체재, 공급자 교섭력, 구매자 교섭력)을 - - 분석하여 산업의 수익성과 경쟁 강도를 평가. + Evaluates industry profitability and competitive intensity by analyzing 5 competitive forces (Existing Competitors, Potential Entrants, Substitutes, Supplier Power, Buyer Power). ' -promptTemplate: '## Porter''s Five Forces 분석 +promptTemplate: '## Porter''s Five Forces Analysis - 이 프로젝트가 포터의 5가지 경쟁 요인을 분석했는지 평가하세요. + Evaluate if the project has analyzed Porter''s 5 competitive forces. - ### 5가지 경쟁 요인: + ### 5 Competitive Forces: - 1. **기존 경쟁자 간 경쟁**: 현재 시장 경쟁 강도는? + 1. **Rivalry Among Existing Competitors**: What is the current market competition intensity? - 2. **잠재적 진입자 위협**: 신규 진입 장벽은? + 2. **Threat of New Entrants**: What are the barriers to entry? - 3. **대체재 위협**: 대체 솔루션/기술의 위협은? + 3. **Threat of Substitutes**: What is the threat from alternative solutions/technologies? - 4. **공급자 교섭력**: 핵심 자원/기술 공급자의 영향력은? + 4. **Bargaining Power of Suppliers**: What is the influence of key resource/technology suppliers? - 5. **구매자 교섭력**: 고객의 협상력과 전환 비용은? + 5. **Bargaining Power of Buyers**: What is the negotiation power and switching cost of customers? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5가지 요인 심층 분석, 전략적 대응 수립 + - 5 points: In-depth analysis of 5 forces, strategic response established - - 4점: 4-5가지 요인 분석, 경쟁 우위 식별 + - 4 points: Analysis of 4-5 forces, competitive advantage identified - - 3점: 3가지 요인 분석 + - 3 points: Analysis of 3 forces - - 2점: 1-2가지 요인만 고려 + - 2 points: Only 1-2 forces considered - - 1점: 경쟁 분석 없음 + - 1 points: No competition analysis ' scoring: min: 1 max: 5 criteria: - 5: 5가지 심층 분석, 전략 대응 - 4: 4-5가지 분석, 경쟁 우위 - 3: 3가지 요인 분석 - 2: 1-2가지만 고려 - 1: 경쟁 분석 없음 + 5: In-depth 5 forces analysis, strategic response + 4: 4-5 forces analyzed, competitive advantage + 3: 3 forces analyzed + 2: 1-2 forces considered + 1: No competition analysis outputSchema: score: number industryRivalry: string @@ -73,5 +70,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Michael Porter, Harvard Business School (1979) - academicReference: Harvard Business Review 게재, 전략경영 필수 도구 + academicReference: Published in Harvard Business Review, essential tool for strategic management requiredSources: either diff --git a/backend/app/techniques/definitions/balance/resource-constraints.yaml b/backend/app/techniques/definitions/balance/resource-constraints.yaml index 096443c..094d255 100644 --- a/backend/app/techniques/definitions/balance/resource-constraints.yaml +++ b/backend/app/techniques/definitions/balance/resource-constraints.yaml @@ -1,6 +1,5 @@ id: resource-constraints name: Resource Constraints Analysis -nameKo: 자원 제약 category: balance applicableHats: - white @@ -9,52 +8,50 @@ evaluationDimensions: - B1 - B3 - B4 -description: '시간, 예산, 인력, 기술 등 가용 자원을 분석하고 +description: 'A technique to analyze available resources (time, budget, manpower, technology) and evaluate feasibility within constraints. - 제약 조건 내에서의 실현 가능성을 평가하는 기법. - - 현실적인 계획 수립의 기초가 됩니다. + Forms the basis for realistic planning. ' -promptTemplate: '## Resource Constraints Analysis 분석 +promptTemplate: '## Resource Constraints Analysis - 프로젝트가 자원 제약을 현실적으로 고려했는지 분석하세요. + Analyze if the project has realistically considered resource constraints. - ### 분석 관점: + ### Analysis Perspectives: - 1. **시간 자원**: 개발 기간을 현실적으로 산정했는가? + 1. **Time Resources**: Is the development timeline estimated realistically? - 2. **인적 자원**: 팀 역량과 규모를 고려했는가? + 2. **Human Resources**: Are team capabilities and scale considered? - 3. **기술 자원**: 기술적 역량과 도구를 파악했는가? + 3. **Technical Resources**: Are technical capabilities and tools identified? - 4. **예산 자원**: 비용을 현실적으로 고려했는가? + 4. **Budget Resources**: Are costs considered realistically? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 모든 자원 제약을 상세히 분석하고 현실적 계획 수립 + - 5 points: Detailed analysis of all resource constraints and realistic planning - - 4점: 주요 자원 제약을 파악하고 대응 + - 4 points: Key resource constraints identified and addressed - - 3점: 일부 제약 인식 + - 3 points: Some constraints recognized - - 2점: 자원 제약 과소평가 + - 2 points: Resource constraints underestimated - - 1점: 자원 제약 무시 + - 1 points: Resource constraints ignored ' scoring: min: 1 max: 5 criteria: - 5: 모든 자원 제약 분석, 현실적 계획 - 4: 주요 제약 파악 및 대응 - 3: 일부 제약 인식 - 2: 제약 과소평가 - 1: 제약 무시 + 5: All constraints analyzed, realistic plan + 4: Key constraints identified and addressed + 3: Some constraints recognized + 2: Constraints underestimated + 1: Constraints ignored outputSchema: score: number timeConstraints: string diff --git a/backend/app/techniques/definitions/balance/technology-readiness-level.yaml b/backend/app/techniques/definitions/balance/technology-readiness-level.yaml index f643b8f..6be465d 100644 --- a/backend/app/techniques/definitions/balance/technology-readiness-level.yaml +++ b/backend/app/techniques/definitions/balance/technology-readiness-level.yaml @@ -1,6 +1,5 @@ id: technology-readiness-level name: Technology Readiness Level -nameKo: 기술성숙도 (TRL) category: balance applicableHats: - white @@ -9,62 +8,60 @@ evaluationDimensions: - B1 - B2 - C1 -description: 'NASA(1974)가 개발하고 ISO 16290:2013으로 국제 표준화된 기술 성숙도 평가 체계. +description: 'Technology maturity assessment system developed by NASA (1974) and standardized as ISO 16290:2013. - TRL 1(기초 연구)부터 TRL 9(실제 운용)까지 9단계로 - - 기술의 개발 단계와 준비 상태를 객관적으로 평가. + Objectively evaluates technology development stage and readiness from TRL 1 (Basic Principle) to TRL 9 (Flight Proven). ' -promptTemplate: '## Technology Readiness Level 분석 +promptTemplate: '## Technology Readiness Level Analysis - 이 프로젝트의 핵심 기술이 어느 TRL 단계에 있는지 평가하세요. + Evaluate which TRL stage the project''s core technology is at. - ### TRL 9단계: + ### TRL 9 Stages: - - **TRL 1**: 기초 원리 관찰 및 보고 + - **TRL 1**: Basic principles observed and reported - - **TRL 2**: 기술 개념 및 응용 공식화 + - **TRL 2**: Technology concept and/or application formulated - - **TRL 3**: 핵심 기능의 분석적/실험적 개념 증명 + - **TRL 3**: Analytical and experimental critical function and/or characteristic proof of concept - - **TRL 4**: 실험실 환경에서 컴포넌트 검증 + - **TRL 4**: Component and/or breadboard validation in laboratory environment - - **TRL 5**: 관련 환경에서 컴포넌트 검증 + - **TRL 5**: Component and/or breadboard validation in relevant environment - - **TRL 6**: 관련 환경에서 시스템/서브시스템 모델 시연 + - **TRL 6**: System/subsystem model or prototype demonstration in a relevant environment - - **TRL 7**: 운영 환경에서 시스템 프로토타입 시연 + - **TRL 7**: System prototype demonstration in an operational environment - - **TRL 8**: 실제 시스템 완성 및 인증 + - **TRL 8**: Actual system completed and qualified through test and demonstration - - **TRL 9**: 운영 환경에서 실제 시스템 검증 + - **TRL 9**: Actual system proven through successful mission operations - ### 점수 기준: + ### Scoring Criteria: - - 5점: TRL 7-9, 프로토타입~실제 운용 단계 + - 5 points: TRL 7-9, Prototype to Operational stage - - 4점: TRL 5-6, 관련 환경에서 검증 + - 4 points: TRL 5-6, Validation in relevant environment - - 3점: TRL 3-4, 실험실 수준 검증 + - 3 points: TRL 3-4, Lab level validation - - 2점: TRL 2, 개념 수준 + - 2 points: TRL 2, Concept level - - 1점: TRL 1 또는 평가 불가 + - 1 points: TRL 1 or Unable to evaluate ' scoring: min: 1 max: 5 criteria: - 5: TRL 7-9, 프로토타입~운용 - 4: TRL 5-6, 관련 환경 검증 - 3: TRL 3-4, 실험실 검증 - 2: TRL 2, 개념 수준 - 1: TRL 1 또는 평가 불가 + 5: TRL 7-9, Prototype~Operational + 4: TRL 5-6, Relevant env validation + 3: TRL 3-4, Lab validation + 2: TRL 2, Concept level + 1: TRL 1 or Unable to evaluate outputSchema: score: number currentTRL: number @@ -79,5 +76,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: NASA (1974) - academicReference: ISO 16290:2013 국제 표준, EU Horizon 2020 필수 평가 + academicReference: ISO 16290:2013 International Standard, EU Horizon 2020 essential evaluation requiredSources: readme_only diff --git a/backend/app/techniques/definitions/balance/trait-transfer.yaml b/backend/app/techniques/definitions/balance/trait-transfer.yaml index 1722070..b595d85 100644 --- a/backend/app/techniques/definitions/balance/trait-transfer.yaml +++ b/backend/app/techniques/definitions/balance/trait-transfer.yaml @@ -1,6 +1,5 @@ id: trait-transfer name: Trait Transfer -nameKo: 특성 전이 category: balance applicableHats: - green @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - B1 - B2 -description: '한 영역의 성공적인 특성을 다른 영역으로 전이하는 기법. +description: 'A technique to transfer successful traits from one domain to another. - 입증된 패턴이나 원리를 새로운 맥락에 적용하여 - - 실현 가능성을 높입니다. + Applies proven patterns or principles to a new context to increase feasibility. ' -promptTemplate: '## Trait Transfer 분석 +promptTemplate: '## Trait Transfer Analysis - 프로젝트가 검증된 특성을 효과적으로 전이했는지 분석하세요. + Analyze if the project has effectively transferred proven traits. - ### 분석 관점: + ### Analysis Perspectives: - 1. **원천 식별**: 어떤 성공 사례에서 특성을 가져왔는가? + 1. **Source Identification**: From which success cases were traits taken? - 2. **특성 추출**: 어떤 핵심 특성을 추출했는가? + 2. **Trait Extraction**: What key traits were extracted? - 3. **적용성 검증**: 새 맥락에서의 적용 가능성을 검토했는가? + 3. **Applicability Verification**: Was applicability in the new context reviewed? - 4. **전이 성공**: 특성 전이가 효과적으로 이루어졌는가? + 4. **Transfer Success**: Was the trait transfer effective? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다양한 소스에서 핵심 특성 추출 및 창의적 적용 + - 5 points: Key traits extracted from diverse sources and creatively applied - - 4점: 명확한 특성 전이와 맥락화 + - 4 points: Clear trait transfer and contextualization - - 3점: 일부 특성 참조 + - 3 points: Some traits referenced - - 2점: 피상적 벤치마킹 + - 2 points: Superficial benchmarking - - 1점: 특성 전이 없음 + - 1 points: No trait transfer ' scoring: min: 1 max: 5 criteria: - 5: 다양한 소스, 창의적 적용 - 4: 명확한 특성 전이 - 3: 일부 특성 참조 - 2: 피상적 벤치마킹 - 1: 특성 전이 없음 + 5: Diverse sources, creative application + 4: Clear trait transfer + 3: Some traits referenced + 2: Superficial benchmarking + 1: No trait transfer outputSchema: score: number sourceTraits: string[] diff --git a/backend/app/techniques/definitions/body/anti-solution.yaml b/backend/app/techniques/definitions/body/anti-solution.yaml index d2c1bbe..eba4d1b 100644 --- a/backend/app/techniques/definitions/body/anti-solution.yaml +++ b/backend/app/techniques/definitions/body/anti-solution.yaml @@ -1,6 +1,5 @@ id: anti-solution name: Anti-Solution Design -nameKo: 반(反)해결책 category: body applicableHats: - black @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - B3 - C3 -description: '"최악의 솔루션"을 먼저 설계해보고 +description: 'Technique to design the "worst solution" first and then reverse it to derive a good solution. - 그것을 뒤집어 좋은 솔루션을 도출하는 기법. - - 무엇을 피해야 하는지 명확히 합니다. + Clarifies what should be avoided. ' -promptTemplate: '## Anti-Solution Design 분석 +promptTemplate: '## Anti-Solution Design Analysis - 프로젝트가 안티-솔루션 사고를 활용했는지 분석하세요. + Analyze if the project utilized anti-solution thinking. - ### 분석 관점: + ### Analysis Perspectives: - 1. **최악 설계**: "최악의 솔루션"을 상상해 보았는가? + 1. **Worst Design**: Did they imagine the "worst solution"? - 2. **피해야 할 것**: 무엇을 피해야 하는지 명확히 했는가? + 2. **What to Avoid**: Did they clarify what to avoid? - 3. **역전 활용**: 최악에서 최선을 도출했는가? + 3. **Reverse Utilization**: Did they derive the best from the worst? - 4. **경계선 정의**: 하지 말아야 할 것의 경계를 정했는가? + 4. **Defining Boundaries**: Did they set boundaries for what not to do? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 안티-솔루션 설계 후 역전으로 최선 도출 + - 5 points: Derived best solution by reversing anti-solution design - - 4점: 피해야 할 것을 명확히 정의 + - 4 points: Clearly defined what to avoid - - 3점: 일부 안티패턴 인식 + - 3 points: Recognized some anti-patterns - - 2점: 부정적 사례 언급만 + - 2 points: Mentioned negative examples only - - 1점: 안티-솔루션 사고 없음 + - 1 points: No anti-solution thinking ' scoring: min: 1 max: 5 criteria: - 5: 안티-솔루션 역전으로 최선 도출 - 4: 피해야 할 것 명확 정의 - 3: 일부 안티패턴 인식 - 2: 부정 사례 언급만 - 1: 안티-솔루션 없음 + 5: Reversed anti-solution to find best + 4: Defined what to avoid + 3: Recognized some anti-patterns + 2: Negative examples only + 1: No anti-solution thinking outputSchema: score: number worstSolution: string @@ -68,4 +65,4 @@ metadata: requiresWebSearch: false requiresRAG: false source: Creative Problem Solving - requiredSources: either +requiredSources: either diff --git a/backend/app/techniques/definitions/body/devil-advocate.yaml b/backend/app/techniques/definitions/body/devil-advocate.yaml index 9d3ecbd..c4e3393 100644 --- a/backend/app/techniques/definitions/body/devil-advocate.yaml +++ b/backend/app/techniques/definitions/body/devil-advocate.yaml @@ -1,6 +1,5 @@ id: devil-advocate name: Devil's Advocate -nameKo: 악마의 옹호자 category: body applicableHats: - black @@ -8,52 +7,50 @@ evaluationDimensions: - A3 - B3 - C3 -description: '의도적으로 반대 입장에서 비판하는 역할을 맡아 +description: 'Technique to intentionally take an opposing position to criticize and find weaknesses in ideas. - 아이디어의 약점을 찾아내는 기법. - - 건설적 비판을 통해 아이디어를 강화합니다. + Strengthens ideas through constructive criticism. ' -promptTemplate: '## Devil''s Advocate 분석 +promptTemplate: '## Devil''s Advocate Analysis - 프로젝트가 악마의 옹호자 역할을 통해 검증했는지 분석하세요. + Analyze if the project validated through the Devil''s Advocate role. - ### 분석 관점: + ### Analysis Perspectives: - 1. **비판적 검토**: 의도적으로 반대 입장에서 검토했는가? + 1. **Critical Review**: Did they intentionally review from an opposing position? - 2. **약점 발굴**: 아이디어의 약점을 적극적으로 찾았는가? + 2. **Weakness Discovery**: Did they actively find weaknesses in the idea? - 3. **반론 대응**: 발견된 약점에 대한 반박을 준비했는가? + 3. **Counterargument Response**: Did they prepare rebuttals for discovered weaknesses? - 4. **아이디어 강화**: 비판을 통해 아이디어가 강화되었는가? + 4. **Idea Strengthening**: Was the idea strengthened through criticism? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 비판, 모든 약점 대응, 아이디어 강화 + - 5 points: Systematic criticism, response to all weaknesses, idea strengthened - - 4점: 주요 약점 식별 및 대응 준비 + - 4 points: Key weaknesses identified and response prepared - - 3점: 일부 비판적 검토 + - 3 points: Some critical review - - 2점: 피상적 검토 + - 2 points: Superficial review - - 1점: 비판적 검토 없음 + - 1 points: No critical review ' scoring: min: 1 max: 5 criteria: - 5: 체계적 비판, 아이디어 강화 - 4: 주요 약점 대응 - 3: 일부 비판적 검토 - 2: 피상적 검토 - 1: 비판 없음 + 5: Systematic criticism, idea strengthened + 4: Key weaknesses response + 3: Some critical review + 2: Superficial review + 1: No critical review outputSchema: score: number critiquesRaised: string[] diff --git a/backend/app/techniques/definitions/body/fmea.yaml b/backend/app/techniques/definitions/body/fmea.yaml index 1068f47..ac29752 100644 --- a/backend/app/techniques/definitions/body/fmea.yaml +++ b/backend/app/techniques/definitions/body/fmea.yaml @@ -1,6 +1,5 @@ id: fmea name: FMEA -nameKo: 고장모드 영향분석 category: body applicableHats: - black @@ -9,58 +8,54 @@ evaluationDimensions: - B3 - B4 - C3 -description: 'US Military(1949)가 개발하고 NASA Apollo 프로그램에서 검증된 위험 분석 기법. +description: 'Risk analysis technique developed by US Military (1949) and validated in NASA Apollo program. - ISO/IEC 60812 표준으로, 잠재적 고장 모드(Failure Mode)를 식별하고 - - 심각도(Severity), 발생 가능성(Occurrence), 검출 가능성(Detection)을 - - 평가하여 위험 우선순위(RPN)를 산출. + ISO/IEC 60812 standard. Identifies potential Failure Modes and calculates Risk Priority Number (RPN) by evaluating Severity, Occurrence, and Detection. ' -promptTemplate: '## FMEA 분석 +promptTemplate: '## FMEA Analysis - 이 프로젝트가 FMEA 관점에서 잠재적 고장을 분석했는지 평가하세요. + Evaluate if the project analyzed potential failures from an FMEA perspective. - ### FMEA 핵심 요소: + ### FMEA Core Elements: - 1. **고장 모드 식별**: 가능한 실패 방식을 열거했는가? + 1. **Failure Mode ID**: Enumerated possible ways of failure? - 2. **영향 분석**: 각 고장이 시스템에 미치는 영향? + 2. **Impact Analysis**: Impact of each failure on the system? - 3. **심각도(S)**: 고장 발생 시 피해의 심각성 (1-10) + 3. **Severity (S)**: Severity of damage if failure occurs (1-10) - 4. **발생도(O)**: 고장 발생 가능성 (1-10) + 4. **Occurrence (O)**: Probability of failure occurrence (1-10) - 5. **검출도(D)**: 고장을 사전에 발견할 수 있는 능력 (1-10) + 5. **Detection (D)**: Ability to detect failure beforehand (1-10) - 6. **RPN 계산**: S × O × D로 위험 우선순위 산출 + 6. **RPN Calculation**: Risk priority calculated as S × O × D - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전한 FMEA, RPN 계산, 개선 조치 수립 + - 5 points: Complete FMEA, RPN calculation, improvement actions established - - 4점: 주요 고장 모드 분석, 대응책 마련 + - 4 points: Key failure modes analyzed, countermeasures prepared - - 3점: 일부 고장 모드 식별 및 영향 분석 + - 3 points: Some failure modes identified and impact analyzed - - 2점: 간략한 위험 요소 언급 + - 2 points: Brief mention of risk factors - - 1점: 고장 분석 없음 + - 1 points: No failure analysis ' scoring: min: 1 max: 5 criteria: - 5: 완전한 FMEA, RPN, 개선 조치 - 4: 주요 고장 분석, 대응책 - 3: 일부 고장 식별, 영향 분석 - 2: 간략한 위험 언급 - 1: 고장 분석 없음 + 5: Complete FMEA, RPN, actions + 4: Key failures analyzed, countermeasures + 3: Some failures identified + 2: Brief risk mention + 1: No failure analysis outputSchema: score: number failureModes: string[] @@ -76,5 +71,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: US Military (1949), NASA Apollo Program - academicReference: ISO/IEC 60812 국제 표준, 자동차/항공/의료 산업 필수 + academicReference: ISO/IEC 60812 International Standard, essential for automotive/aerospace/medical industries requiredSources: either diff --git a/backend/app/techniques/definitions/body/pre-mortem.yaml b/backend/app/techniques/definitions/body/pre-mortem.yaml index 4177096..3087b22 100644 --- a/backend/app/techniques/definitions/body/pre-mortem.yaml +++ b/backend/app/techniques/definitions/body/pre-mortem.yaml @@ -1,6 +1,5 @@ id: pre-mortem name: Pre-mortem Analysis -nameKo: 사전 부검 category: body applicableHats: - black @@ -9,52 +8,50 @@ evaluationDimensions: - B3 - B4 - C3 -description: 'Gary Klein이 개발한 기법으로, +description: 'Technique developed by Gary Klein. - 프로젝트가 실패했다고 가정하고 - - "왜 실패했을까?"를 역추적하여 위험을 발견합니다. + Assumes the project has failed and back-tracks "Why did it fail?" to discover risks. ' -promptTemplate: '## Pre-mortem Analysis 분석 +promptTemplate: '## Pre-mortem Analysis - 프로젝트가 사전 부검 분석을 수행했는지 분석하세요. + Analyze if the project performed a Pre-mortem analysis. - ### 분석 관점: + ### Analysis Perspectives: - 1. **실패 가정**: "프로젝트가 실패했다"고 가정했는가? + 1. **Failure Assumption**: Did they assume "The project failed"? - 2. **원인 역추적**: 실패 원인을 역으로 추적했는가? + 2. **Cause Backtracking**: Did they trace back the causes of failure? - 3. **조기 경고**: 실패 조짐이 될 수 있는 신호를 식별했는가? + 3. **Early Warning**: Did they identify signals that could be signs of failure? - 4. **예방 전략**: 식별된 위험에 대한 예방책이 있는가? + 4. **Prevention Strategy**: Are there preventive measures for identified risks? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전한 사전 부검, 조기 경고 시스템, 예방 전략 + - 5 points: Complete pre-mortem, early warning system, prevention strategy - - 4점: 주요 실패 원인 분석 및 대응 + - 4 points: Analysis of key failure causes and response - - 3점: 일부 실패 가능성 고려 + - 3 points: Considered some failure possibilities - - 2점: 간략한 위험 언급 + - 2 points: Brief mention of risks - - 1점: 사전 부검 없음 + - 1 points: No pre-mortem ' scoring: min: 1 max: 5 criteria: - 5: 완전한 사전 부검, 예방 전략 - 4: 주요 실패 원인 분석 - 3: 일부 실패 고려 - 2: 간략한 위험 언급 - 1: 사전 부검 없음 + 5: Complete pre-mortem, prevention strategy + 4: Key failure causes analyzed + 3: Some failure possibilities + 2: Brief risk mention + 1: No pre-mortem outputSchema: score: number assumedFailure: string diff --git a/backend/app/techniques/definitions/body/reverse-brainstorming.yaml b/backend/app/techniques/definitions/body/reverse-brainstorming.yaml index baf733b..f21ff97 100644 --- a/backend/app/techniques/definitions/body/reverse-brainstorming.yaml +++ b/backend/app/techniques/definitions/body/reverse-brainstorming.yaml @@ -1,6 +1,5 @@ id: reverse-brainstorming name: Reverse Brainstorming -nameKo: 역브레인스토밍 category: body applicableHats: - black @@ -9,52 +8,50 @@ evaluationDimensions: - B3 - B4 - C3 -description: '"어떻게 하면 실패할 수 있을까?"라고 역으로 질문하여 +description: 'Technique to discover potential problems by asking "How could this fail?". - 잠재적 문제점을 발견하는 기법. - - 부정적 시나리오를 통해 위험을 사전에 식별합니다. + Identifies risks in advance through negative scenarios. ' -promptTemplate: '## Reverse Brainstorming 분석 +promptTemplate: '## Reverse Brainstorming Analysis - 프로젝트가 역발상을 통해 위험을 식별했는지 분석하세요. + Analyze if the project identified risks through reverse thinking. - ### 분석 관점: + ### Analysis Perspectives: - 1. **실패 시나리오**: "어떻게 하면 실패할까?"를 고려했는가? + 1. **Failure Scenarios**: Did they consider "How could it fail?"? - 2. **역전 발상**: 문제를 뒤집어 생각했는가? + 2. **Reverse Thinking**: Did they think about the problem in reverse? - 3. **위험 발견**: 역발상에서 위험 요소를 도출했는가? + 3. **Risk Discovery**: Did they derive risk factors from reverse thinking? - 4. **예방 조치**: 발견된 위험에 대한 대응책이 있는가? + 4. **Preventive Measures**: Are there countermeasures for discovered risks? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 역발상, 다양한 실패 시나리오, 예방책 수립 + - 5 points: Systematic reverse thinking, various failure scenarios, preventive measures - - 4점: 주요 실패 가능성 식별 및 대응 + - 4 points: Key failure possibilities identified and addressed - - 3점: 일부 부정적 시나리오 고려 + - 3 points: Some negative scenarios considered - - 2점: 피상적 위험 언급 + - 2 points: Superficial risk mention - - 1점: 역발상 없음 + - 1 points: No reverse thinking ' scoring: min: 1 max: 5 criteria: - 5: 체계적 역발상, 예방책 수립 - 4: 주요 실패 식별 및 대응 - 3: 일부 부정 시나리오 - 2: 피상적 위험 - 1: 역발상 없음 + 5: Systematic reverse thinking, measures + 4: Key failure identified + 3: Some negative scenarios + 2: Superficial risk + 1: No reverse thinking outputSchema: score: number failureScenarios: string[] diff --git a/backend/app/techniques/definitions/body/risk-matrix.yaml b/backend/app/techniques/definitions/body/risk-matrix.yaml index 576a48f..8a8abb6 100644 --- a/backend/app/techniques/definitions/body/risk-matrix.yaml +++ b/backend/app/techniques/definitions/body/risk-matrix.yaml @@ -1,6 +1,5 @@ id: risk-matrix name: Risk Matrix Analysis -nameKo: 위험 매트릭스 category: body applicableHats: - black @@ -8,28 +7,20 @@ evaluationDimensions: - B3 - B4 - C3 -description: '리스크를 발생 가능성(Likelihood)과 영향도(Impact)의 - - 2차원 매트릭스로 분류하여 우선순위를 결정하는 기법. +description: 'Technique to prioritize risks by classifying them into a 2D matrix of Likelihood and Impact. ' -promptTemplate: "## Risk Matrix Analysis (리스크 매트릭스 분석)\n\n이 프로젝트의 리스크를 발생 가능성과 영향도로\ - \ 분류하여 평가하세요.\n\n### 리스크 매트릭스:\n```\n │ 영향도 낮음 │ 영향도 중간 │ 영향도 높음\n────────────┼────────────┼────────────┼────────────\n\ - 가능성 높음 │ 주의 │ 경고 │ 위험\n가능성 중간 │ 관찰 │ 주의 │ 경고\n가능성 낮음\ - \ │ 수용 │ 관찰 │ 주의\n```\n\n### 분석 관점:\n1. **기술적 리스크**: 구현 실패, 성능 문제,\ - \ 보안 취약점\n2. **비즈니스 리스크**: 시장 변화, 경쟁, 수익 모델\n3. **운영 리스크**: 확장성, 유지보수, 팀 역량\n4.\ - \ **외부 리스크**: 규제, 법적 문제, 의존성\n\n### 점수 기준:\n- 5점: 모든 주요 리스크 식별 + 대응 계획 수립\n- 4점:\ - \ 대부분 리스크 식별 + 일부 대응 계획\n- 3점: 주요 리스크 인식, 대응 계획 미흡\n- 2점: 리스크 인식이 부분적\n- 1점: 리스크\ - \ 분석 없음\n" +promptTemplate: "## Risk Matrix Analysis\n\nEvaluate the risks of this project by classifying them by likelihood and impact.\n\n### Risk Matrix:\n```\n │ Impact Low │ Impact Med │ Impact High\n────────────┼─────────────┼─────────────┼─────────────\nProb High │ Caution │ Warning │ Danger\nProb Med │ Observe │ Caution │ Warning\nProb Low │ Accept │ Observe │ Caution\n```\n\n### Analysis Perspectives:\n1. **Technical Risks**: Implementation failure, performance issues, security vulnerabilities\n2. **Business Risks**: Market changes, competition, revenue model\n3. **Operational Risks**: Scalability, maintenance, team capability\n4. **External Risks**: Regulations, legal issues, dependencies\n\n### Scoring Criteria:\n- 5 points: All key risks identified + Mitigation plans established\n- 4 points: Most risks identified + Some mitigation plans\n- 3 points: Key risks recognized, mitigation plans insufficient\n- 2 points: Partial risk recognition\n\ + - 1 points: No risk analysis\n" scoring: min: 1 max: 5 criteria: - 5: 전체 리스크 식별 + 대응 계획 - 4: 대부분 식별 + 일부 대응 - 3: 주요 리스크 인식, 대응 미흡 - 2: 부분적 리스크 인식 - 1: 리스크 분석 없음 + 5: All key risks identified + Plans + 4: Most risks identified + Some plans + 3: Key risks recognized, plans weak + 2: Partial risk recognition + 1: No risk analysis outputSchema: score: number technicalRisks: object[] diff --git a/backend/app/techniques/definitions/body/swot-analysis.yaml b/backend/app/techniques/definitions/body/swot-analysis.yaml index 38104c9..890c519 100644 --- a/backend/app/techniques/definitions/body/swot-analysis.yaml +++ b/backend/app/techniques/definitions/body/swot-analysis.yaml @@ -1,6 +1,5 @@ id: swot-analysis name: SWOT Analysis -nameKo: SWOT 분석 category: body applicableHats: - white @@ -10,63 +9,61 @@ evaluationDimensions: - A4 - B3 - B4 -description: 'Albert Humphrey(Stanford Research Institute)가 체계화한 전략 분석 도구. +description: 'Strategic analysis tool systematized by Albert Humphrey (Stanford Research Institute). - Strengths(강점), Weaknesses(약점), Opportunities(기회), Threats(위협)의 - - 내부/외부 요인을 분석하여 전략적 의사결정을 지원. + Supports strategic decision making by analyzing internal/external factors of Strengths, Weaknesses, Opportunities, and Threats. ' -promptTemplate: '## SWOT 분석 +promptTemplate: '## SWOT Analysis - 이 프로젝트가 SWOT 4가지 요소를 체계적으로 분석했는지 평가하세요. + Evaluate if the project systematically analyzed the 4 elements of SWOT. - ### SWOT 4가지 요소: + ### SWOT 4 Elements: - 1. **Strengths (강점)**: 경쟁 우위가 되는 내부 역량? + 1. **Strengths**: Internal capabilities that become competitive advantages? - 2. **Weaknesses (약점)**: 개선이 필요한 내부 한계? + 2. **Weaknesses**: Internal limitations that need improvement? - 3. **Opportunities (기회)**: 활용 가능한 외부 환경? + 3. **Opportunities**: External environment that can be leveraged? - 4. **Threats (위협)**: 대비해야 할 외부 리스크? + 4. **Threats**: External risks to prepare for? - ### 전략 도출: + ### Strategy Derivation: - - SO전략: 강점으로 기회 활용 + - SO Strategy: Use strengths to leverage opportunities - - WO전략: 약점 보완하며 기회 포착 + - WO Strategy: Overcome weaknesses to capture opportunities - - ST전략: 강점으로 위협 대응 + - ST Strategy: Use strengths to counter threats - - WT전략: 약점과 위협 최소화 + - WT Strategy: Minimize weaknesses and threats - ### 점수 기준: + ### Scoring Criteria: - - 5점: 4가지 요소 심층 분석, TOWS 전략 도출 + - 5 points: In-depth analysis of 4 elements, TOWS strategy derived - - 4점: 4가지 요소 분석, 대응 전략 수립 + - 4 points: Analysis of 4 elements, response strategy established - - 3점: 강점/약점 또는 기회/위협 분석 + - 3 points: Analysis of Strengths/Weaknesses or Opportunities/Threats - - 2점: 일부 요소만 간략히 언급 + - 2 points: Brief mention of some elements - - 1점: SWOT 분석 없음 + - 1 points: No SWOT analysis ' scoring: min: 1 max: 5 criteria: - 5: 4요소 심층분석, TOWS 전략 - 4: 4요소 분석, 대응 전략 - 3: 내부 또는 외부 분석 - 2: 일부 요소만 언급 - 1: SWOT 분석 없음 + 5: Deep 4 element analysis, TOWS strategy + 4: 4 element analysis, response strategy + 3: Internal or External analysis + 2: Some elements mentioned + 1: No SWOT analysis outputSchema: score: number strengths: string[] @@ -81,5 +78,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Albert Humphrey, Stanford Research Institute (1960s) - academicReference: 전 산업 채택, MBA 필수 프레임워크 + academicReference: Adopted across all industries, MBA essential framework requiredSources: either diff --git a/backend/app/techniques/definitions/body/zombie-apocalypse.yaml b/backend/app/techniques/definitions/body/zombie-apocalypse.yaml index 7910f81..8d0f874 100644 --- a/backend/app/techniques/definitions/body/zombie-apocalypse.yaml +++ b/backend/app/techniques/definitions/body/zombie-apocalypse.yaml @@ -1,6 +1,5 @@ id: zombie-apocalypse name: Zombie Apocalypse Scenario -nameKo: 좀비 아포칼립스 시나리오 category: body applicableHats: - black @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - B3 - B4 -description: '극단적인 재난 시나리오를 상상하여 +description: 'Technique to test system survivability and resilience by imagining extreme disaster scenarios. - 시스템의 생존력과 복원력을 테스트하는 기법. - - 극한 상황에서도 작동하는 설계를 추구합니다. + Pursues design that works even in extreme situations. ' -promptTemplate: '## Zombie Apocalypse Scenario 분석 +promptTemplate: '## Zombie Apocalypse Scenario Analysis - 프로젝트가 극단적 시나리오에서의 생존을 고려했는지 분석하세요. + Analyze if the project considered survival in extreme scenarios. - ### 분석 관점: + ### Analysis Perspectives: - 1. **극단 시나리오**: 최악의 상황을 상상해 보았는가? + 1. **Extreme Scenarios**: Did they imagine worst-case scenarios? - 2. **핵심 기능**: 극한 상황에서도 유지해야 할 핵심은? + 2. **Core Functions**: What are the core things to maintain in extreme situations? - 3. **생존 모드**: 최소한의 자원으로 작동하는 모드가 있는가? + 3. **Survival Mode**: Is there a mode that works with minimal resources? - 4. **복원 계획**: 재난 후 복구 계획이 있는가? + 4. **Recovery Plan**: Is there a post-disaster recovery plan? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 극단 시나리오 분석, 생존 모드, 복구 계획 존재 + - 5 points: Extreme scenario analysis, survival mode, recovery plan exist - - 4점: 주요 극단 상황 대비 + - 4 points: Prepared for major extreme situations - - 3점: 일부 극한 상황 고려 + - 3 points: Some extreme situations considered - - 2점: 정상 상황만 고려 + - 2 points: Only normal situations considered - - 1점: 극단 시나리오 무시 + - 1 points: Extreme scenarios ignored ' scoring: min: 1 max: 5 criteria: - 5: 극단 분석, 생존 모드, 복구 계획 - 4: 주요 극단 상황 대비 - 3: 일부 극한 고려 - 2: 정상 상황만 - 1: 극단 무시 + 5: Extreme analysis, survival mode, plan + 4: Major extreme prep + 3: Some extreme considered + 2: Normal only + 1: Extreme ignored outputSchema: score: number extremeScenarios: string[] diff --git a/backend/app/techniques/definitions/cellar/balanced-scorecard.yaml b/backend/app/techniques/definitions/cellar/balanced-scorecard.yaml index 8c3dc6e..1cc100f 100644 --- a/backend/app/techniques/definitions/cellar/balanced-scorecard.yaml +++ b/backend/app/techniques/definitions/cellar/balanced-scorecard.yaml @@ -1,6 +1,5 @@ id: balanced-scorecard name: Balanced Scorecard -nameKo: 균형성과표 category: cellar applicableHats: - blue @@ -10,32 +9,52 @@ evaluationDimensions: - C1 - C4 - D1 -description: 'Robert Kaplan & David Norton(Harvard Business School, 1992)이 개발한 전략 - 관리 도구. +description: 'Strategic management tool developed by Robert Kaplan & David Norton (Harvard Business School, 1992). - 재무(Financial), 고객(Customer), 내부 프로세스(Internal Process), + Measures balanced performance from 4 perspectives: Financial, Customer, Internal Process, and Learning & Growth. - 학습과 성장(Learning & Growth) 4가지 관점에서 균형 잡힌 성과 측정. + Selected as one of HBR''s "75 Most Influential Management Ideas". - HBR "경영 역사상 가장 영향력 있는 75대 아이디어" 선정. + ' +promptTemplate: '## Balanced Scorecard Analysis + + + Evaluate if the project measures performance from the 4 BSC perspectives. + + + ### BSC 4 Perspectives: + + 1. **Financial**: How should we appear to shareholders/investors? (Profitability, growth, ROI) + + 2. **Customer**: How should we appear to customers? (Satisfaction, market share, brand awareness) + + 3. **Internal Process**: What processes must we excel at? (Efficiency, quality, innovation speed) + + 4. **Learning & Growth**: How will we sustain our ability to change and improve? (Employee capability, infrastructure, culture) + + + ### Scoring Criteria: + + - 5 points: KPIs defined for all 4 perspectives, clear causal relationships + + - 4 points: 4 perspectives considered, mostly measurable + + - 3 points: Only 2-3 perspectives defined + + - 2 points: Focused only on financial perspective + + - 1 points: No performance measurement system ' -promptTemplate: "## Balanced Scorecard 분석\n\n이 프로젝트가 BSC 4가지 관점에서 성과를 측정하는지 평가하세요.\n\ - \n### BSC 4가지 관점:\n1. **재무 관점**: 주주/투자자에게 어떻게 보여야 하는가?\n - 수익성, 성장률, ROI 등\n2.\ - \ **고객 관점**: 고객에게 어떻게 보여야 하는가?\n - 고객 만족, 시장 점유율, 브랜드 인지도 등\n3. **내부 프로세스 관점**:\ - \ 어떤 프로세스에서 뛰어나야 하는가?\n - 운영 효율성, 품질, 혁신 속도 등\n4. **학습과 성장 관점**: 어떻게 변화하고 개선해야\ - \ 하는가?\n - 직원 역량, 기술 인프라, 조직 문화 등\n\n### 점수 기준:\n- 5점: 4가지 관점 모두 KPI 정의, 인과관계\ - \ 명확\n- 4점: 4가지 관점 고려, 대부분 측정 가능\n- 3점: 2-3가지 관점만 정의\n- 2점: 재무 관점만 집중\n- 1점: 성과\ - \ 측정 체계 없음\n" scoring: min: 1 max: 5 criteria: - 5: 4관점 KPI, 인과관계 명확 - 4: 4관점 고려, 측정 가능 - 3: 2-3관점만 정의 - 2: 재무 관점만 - 1: 성과 측정 없음 + 5: 4 perspective KPIs, clear causality + 4: 4 perspectives considered, measurable + 3: 2-3 perspectives defined + 2: Financial only + 1: No measurement outputSchema: score: number financialPerspective: string @@ -51,5 +70,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Robert Kaplan & David Norton, Harvard Business School (1992) - academicReference: HBR '75대 경영 아이디어' 선정, Fortune 1000 기업 50%+ 도입 + academicReference: Selected as HBR '75 Big Ideas', adopted by 50%+ of Fortune 1000 companies requiredSources: either diff --git a/backend/app/techniques/definitions/cellar/business-model-canvas.yaml b/backend/app/techniques/definitions/cellar/business-model-canvas.yaml index b50f245..5b3ff78 100644 --- a/backend/app/techniques/definitions/cellar/business-model-canvas.yaml +++ b/backend/app/techniques/definitions/cellar/business-model-canvas.yaml @@ -1,6 +1,5 @@ id: business-model-canvas name: Business Model Canvas -nameKo: 비즈니스 모델 캔버스 category: cellar applicableHats: - blue @@ -10,64 +9,60 @@ evaluationDimensions: - A3 - A4 - D1 -description: 'Alexander Osterwalder(2005)가 개발한 비즈니스 모델 시각화 도구. +description: 'Business model visualization tool developed by Alexander Osterwalder (2005). - 9가지 구성 요소(고객 세그먼트, 가치 제안, 채널, 고객 관계, 수익원, - - 핵심 자원, 핵심 활동, 핵심 파트너십, 비용 구조)로 - - 비즈니스 모델을 한눈에 파악하고 설계. + Visualizes and designs business models with 9 building blocks: Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partnerships, Cost Structure. ' -promptTemplate: '## Business Model Canvas 분석 +promptTemplate: '## Business Model Canvas Analysis - 이 프로젝트가 BMC 9가지 요소를 명확히 정의했는지 평가하세요. + Evaluate if the project clearly defined the 9 BMC elements. - ### BMC 9가지 구성 요소: + ### BMC 9 Building Blocks: - 1. **Customer Segments**: 누구를 위한 가치인가? + 1. **Customer Segments**: Who are we creating value for? - 2. **Value Propositions**: 어떤 가치를 제공하는가? + 2. **Value Propositions**: What value do we deliver? - 3. **Channels**: 어떻게 가치를 전달하는가? + 3. **Channels**: How do we reach customers? - 4. **Customer Relationships**: 고객과 어떤 관계를 맺는가? + 4. **Customer Relationships**: What type of relationship do we establish? - 5. **Revenue Streams**: 어떻게 수익을 창출하는가? + 5. **Revenue Streams**: How do we generate revenue? - 6. **Key Resources**: 핵심 자원은 무엇인가? + 6. **Key Resources**: What key resources are required? - 7. **Key Activities**: 핵심 활동은 무엇인가? + 7. **Key Activities**: What key activities do we perform? - 8. **Key Partnerships**: 핵심 파트너는 누구인가? + 8. **Key Partnerships**: Who are our key partners? - 9. **Cost Structure**: 비용 구조는 어떠한가? + 9. **Cost Structure**: What are the important costs? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 9가지 요소 모두 명확, 요소 간 연계 설명 + - 5 points: All 9 elements clear, connections explained - - 4점: 7-8가지 요소 정의, 핵심 요소 명확 + - 4 points: 7-8 elements defined, key elements clear - - 3점: 5-6가지 요소 정의 + - 3 points: 5-6 elements defined - - 2점: 3-4가지 요소만 언급 + - 2 points: Only 3-4 elements mentioned - - 1점: 비즈니스 모델 불명확 + - 1 points: Business model unclear ' scoring: min: 1 max: 5 criteria: - 5: 9가지 명확, 연계 설명 - 4: 7-8가지, 핵심 명확 - 3: 5-6가지 정의 - 2: 3-4가지만 언급 - 1: 비즈니스 모델 불명확 + 5: 9 elements clear, connections explained + 4: 7-8 elements, key elements clear + 3: 5-6 elements defined + 2: 3-4 elements mentioned + 1: Business model unclear outputSchema: score: number customerSegments: string @@ -86,5 +81,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Alexander Osterwalder (2005) - academicReference: 스타트업 표준 도구, 'Business Model Generation' 베스트셀러 + academicReference: Startup standard tool, 'Business Model Generation' bestseller requiredSources: either diff --git a/backend/app/techniques/definitions/cellar/consensus-building.yaml b/backend/app/techniques/definitions/cellar/consensus-building.yaml index fd872f8..9d9c7d4 100644 --- a/backend/app/techniques/definitions/cellar/consensus-building.yaml +++ b/backend/app/techniques/definitions/cellar/consensus-building.yaml @@ -1,58 +1,57 @@ id: consensus-building name: Consensus Building -nameKo: 합의 형성 category: cellar applicableHats: - blue evaluationDimensions: - D3 - D4 -description: '여러 관점과 평가 결과를 종합하여 균형 잡힌 합의점을 도출하는 기법. +description: 'Technique to synthesize various perspectives and evaluation results to reach a balanced consensus. - 상충되는 의견들 사이에서 최적의 결론을 찾아내는 과정. + Process of finding the optimal conclusion among conflicting opinions. ' -promptTemplate: '## Consensus Building (합의 도출) +promptTemplate: '## Consensus Building Analysis - 여러 평가 관점을 종합하여 균형 잡힌 결론을 도출하세요. + Synthesize multiple evaluation perspectives to reach a balanced conclusion. - ### 분석 관점: + ### Analysis Perspectives: - 1. **공통점 식별**: 모든 관점에서 동의하는 부분은? + 1. **Common Ground**: What parts do all perspectives agree on? - 2. **갈등 지점**: 관점 간 상충되는 부분은? + 2. **Conflict Points**: Where do perspectives conflict? - 3. **가중치 결정**: 어떤 관점에 더 무게를 둘 것인가? + 3. **Weighting**: Which perspective should be weighted more? - 4. **절충안 도출**: 갈등을 해결할 수 있는 절충안은? + 4. **Compromise**: What compromise can resolve conflicts? - 5. **최종 합의**: 모든 것을 고려한 최종 결론은? + 5. **Final Consensus**: What is the final conclusion considering everything? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 모든 관점을 균형있게 종합, 명확한 결론 + - 5 points: Balanced synthesis of all perspectives, clear conclusion - - 4점: 대부분 관점 종합, 일부 누락 + - 4 points: Synthesis of most perspectives, some missing - - 3점: 주요 관점만 종합 + - 3 points: Synthesis of key perspectives only - - 2점: 일부 관점만 반영, 편향됨 + - 2 points: Only some perspectives reflected, biased - - 1점: 종합 없이 단일 관점만 반영 + - 1 points: No synthesis, reflects single perspective ' scoring: min: 1 max: 5 criteria: - 5: 모든 관점 균형있게 종합 - 4: 대부분 관점 종합 - 3: 주요 관점만 종합 - 2: 편향된 종합 - 1: 단일 관점만 반영 + 5: Balanced synthesis, clear conclusion + 4: Most perspectives synthesized + 3: Key perspectives synthesized + 2: Biased synthesis + 1: Single perspective only outputSchema: score: number commonGround: string[] diff --git a/backend/app/techniques/definitions/cellar/indigenous-wisdom.yaml b/backend/app/techniques/definitions/cellar/indigenous-wisdom.yaml index bf1dc27..30585a1 100644 --- a/backend/app/techniques/definitions/cellar/indigenous-wisdom.yaml +++ b/backend/app/techniques/definitions/cellar/indigenous-wisdom.yaml @@ -1,6 +1,5 @@ id: indigenous-wisdom name: Indigenous Wisdom Integration -nameKo: 토착 지혜 category: cellar applicableHats: - blue @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - C1 - D1 -description: '다양한 문화권의 전통 지혜와 현대적 접근을 +description: 'Technique integrating traditional wisdom from various cultures with modern approaches. - 통합하는 기법. 장기적 지속 가능성과 - - 전체론적 관점을 추구합니다. + Pursues long-term sustainability and holistic perspectives. ' -promptTemplate: '## Indigenous Wisdom Integration 분석 +promptTemplate: '## Indigenous Wisdom Integration Analysis - 프로젝트가 전통적 지혜와 지속 가능성을 고려했는지 분석하세요. + Analyze if the project considered traditional wisdom and sustainability. - ### 분석 관점: + ### Analysis Perspectives: - 1. **전체론적 시각**: 부분이 아닌 전체를 보았는가? + 1. **Holistic View**: Did it see the whole rather than parts? - 2. **장기 관점**: 7세대 후를 고려했는가? + 2. **Long-term Perspective**: Did it consider 7 generations ahead? - 3. **자연과 조화**: 자연/환경과의 조화를 고려했는가? + 3. **Harmony with Nature**: Did it consider harmony with nature/environment? - 4. **커뮤니티 영향**: 공동체에 미치는 영향을 고려했는가? + 4. **Community Impact**: Did it consider impact on the community? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 전체론적, 장기적, 지속 가능한 관점 통합 + - 5 points: Integrated holistic, long-term, sustainable perspectives - - 4점: 장기적 영향 고려 + - 4 points: Long-term impact considered - - 3점: 일부 전체론적 시각 + - 3 points: Some holistic views - - 2점: 단기 관점 중심 + - 2 points: Short-term focused - - 1점: 전체론적 관점 없음 + - 1 points: No holistic perspective ' scoring: min: 1 max: 5 criteria: - 5: 전체론적, 장기적, 지속 가능 - 4: 장기적 영향 고려 - 3: 일부 전체론적 - 2: 단기 관점 - 1: 전체론 없음 + 5: Holistic, long-term, sustainable + 4: Long-term impact considered + 3: Some holistic views + 2: Short-term focused + 1: No holistic perspective outputSchema: score: number holisticView: string diff --git a/backend/app/techniques/definitions/cellar/meta-analysis.yaml b/backend/app/techniques/definitions/cellar/meta-analysis.yaml index e3803af..b6b6725 100644 --- a/backend/app/techniques/definitions/cellar/meta-analysis.yaml +++ b/backend/app/techniques/definitions/cellar/meta-analysis.yaml @@ -1,6 +1,5 @@ id: meta-analysis name: Meta-analysis -nameKo: 메타 분석 category: cellar applicableHats: - blue @@ -9,52 +8,50 @@ evaluationDimensions: - A1 - B2 - D1 -description: '여러 분석 결과를 종합하여 +description: 'Technique to synthesize multiple analysis results to derive higher-level patterns and insights. - 상위 수준의 패턴과 인사이트를 도출하는 기법. - - 개별 분석을 넘어 전체적 그림을 봅니다. + Looks at the big picture beyond individual analyses. ' -promptTemplate: '## Meta-analysis 분석 +promptTemplate: '## Meta-analysis - 프로젝트가 다양한 분석을 종합하여 메타 인사이트를 도출했는지 분석하세요. + Analyze if the project derived meta-insights by synthesizing various analyses. - ### 분석 관점: + ### Analysis Perspectives: - 1. **다중 분석**: 여러 관점에서 분석했는가? + 1. **Multiple Analyses**: Was it analyzed from multiple perspectives? - 2. **패턴 발견**: 분석들에서 공통 패턴을 발견했는가? + 2. **Pattern Discovery**: Were common patterns found in analyses? - 3. **상충점 해결**: 상충되는 발견들을 어떻게 처리했는가? + 3. **Conflict Resolution**: How were conflicting findings handled? - 4. **종합 인사이트**: 상위 수준의 통찰을 도출했는가? + 4. **Comprehensive Insight**: Were higher-level insights derived? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다중 분석 종합, 상위 패턴 발견, 통합 인사이트 + - 5 points: Multiple analyses synthesized, high-level patterns found, integrated insight - - 4점: 분석 결과 종합 및 패턴 도출 + - 4 points: Analysis results synthesized and patterns derived - - 3점: 일부 분석 종합 + - 3 points: Some analyses synthesized - - 2점: 개별 분석 나열 + - 2 points: Individual analyses listed - - 1점: 종합 없음 + - 1 points: No synthesis ' scoring: min: 1 max: 5 criteria: - 5: 다중 분석, 상위 패턴, 통합 인사이트 - 4: 분석 종합 및 패턴 - 3: 일부 분석 종합 - 2: 개별 분석 나열 - 1: 종합 없음 + 5: Multiple analyses synthesized, patterns, insight + 4: Synthesized and patterns derived + 3: Some synthesis + 2: Individual analyses listed + 1: No synthesis outputSchema: score: number analysesPerformed: string[] diff --git a/backend/app/techniques/definitions/cellar/priority-matrix.yaml b/backend/app/techniques/definitions/cellar/priority-matrix.yaml index 01ebda8..6660d30 100644 --- a/backend/app/techniques/definitions/cellar/priority-matrix.yaml +++ b/backend/app/techniques/definitions/cellar/priority-matrix.yaml @@ -1,35 +1,26 @@ id: priority-matrix name: Priority Matrix -nameKo: 우선순위 매트릭스 category: cellar applicableHats: - blue evaluationDimensions: - C5 - D4 -description: '여러 요소들을 중요도와 긴급도(또는 영향도와 노력도)의 +description: 'Technique to classify elements into a 2D matrix of Importance and Urgency (or Impact and Effort) to determine priorities. - 2차원 매트릭스로 분류하여 우선순위를 결정하는 기법. - - Eisenhower Matrix의 변형. + Variation of Eisenhower Matrix. ' -promptTemplate: "## Priority Matrix (우선순위 매트릭스)\n\n이 프로젝트의 개선점과 다음 단계를 우선순위로 분류하세요.\n\ - \n### 우선순위 매트릭스:\n```\n │ 영향도 낮음 │ 영향도 높음\n────────────┼────────────┼────────────\n\ - 노력 낮음 │ 선택적 │ 즉시 실행\n노력 높음 │ 제외 │ 계획 수립\n```\n\n### 분석 관점:\n1. **즉시\ - \ 실행 (Quick Wins)**: 적은 노력으로 큰 효과\n2. **계획 수립 (Major Projects)**: 큰 노력이지만 큰 효과\n\ - 3. **선택적 (Fill-ins)**: 여유 있을 때 진행\n4. **제외 (Thankless Tasks)**: 투자 대비 효과 낮음\n\n\ - ### 점수 기준:\n- 5점: 우선순위가 명확하고 실행 계획이 구체적\n- 4점: 우선순위 설정됨, 계획은 부분적\n- 3점: 우선순위 인식\ - \ 있으나 명확하지 않음\n- 2점: 우선순위 없이 나열만\n- 1점: 다음 단계에 대한 고려 없음\n" +promptTemplate: "## Priority Matrix Analysis\n\nPrioritize the improvements and next steps of this project.\n\n### Priority Matrix:\n```\n │ Impact Low │ Impact High\n────────────┼─────────────┼─────────────\nEffort Low │ Fill-ins │ Quick Wins\nEffort High │ Thankless │ Major Proj\n```\n\n### Analysis Perspectives:\n1. **Quick Wins**: Low effort, high impact\n2. **Major Projects**: High effort, high impact\n3. **Fill-ins**: Do when spare time available\n4. **Thankless Tasks**: High effort, low impact\n\n### Scoring Criteria:\n- 5 points: Clear priorities and concrete execution plan\n- 4 points: Priorities set, plan is partial\n- 3 points: Priorities recognized but unclear\n- 2 points: Listed without priority\n- 1 points: No consideration of next steps\n" scoring: min: 1 max: 5 criteria: - 5: 명확한 우선순위 + 구체적 계획 - 4: 우선순위 설정, 부분적 계획 - 3: 우선순위 인식 있으나 불명확 - 2: 우선순위 없이 나열 - 1: 다음 단계 고려 없음 + 5: Clear priorities + Concrete plan + 4: Priorities set, partial plan + 3: Priorities recognized but unclear + 2: Listed without priority + 1: No next steps outputSchema: score: number quickWins: string[] diff --git a/backend/app/techniques/definitions/cellar/six-thinking-hats.yaml b/backend/app/techniques/definitions/cellar/six-thinking-hats.yaml index 9052b25..05807b8 100644 --- a/backend/app/techniques/definitions/cellar/six-thinking-hats.yaml +++ b/backend/app/techniques/definitions/cellar/six-thinking-hats.yaml @@ -1,6 +1,5 @@ id: six-thinking-hats name: Six Thinking Hats Integration -nameKo: 6색 사고모자 통합 category: cellar applicableHats: - blue @@ -8,56 +7,52 @@ evaluationDimensions: - A1 - B2 - D1 -description: 'Edward de Bono의 Six Thinking Hats를 활용하여 - - 6가지 관점(사실, 감정, 비판, 낙관, 창의, 통합)에서 - - 종합적으로 분석하고 통합합니다. +description: 'Utilizes Edward de Bono''s Six Thinking Hats to comprehensively analyze and integrate from 6 perspectives (Facts, Emotions, Cautions, Benefits, Creativity, Process). ' -promptTemplate: '## Six Thinking Hats Integration 분석 +promptTemplate: '## Six Thinking Hats Integration Analysis - 프로젝트가 다양한 관점을 통합적으로 고려했는지 분석하세요. + Analyze if the project considered various perspectives comprehensively. - ### 분석 관점: + ### Analysis Perspectives: - 1. **White Hat**: 사실과 데이터를 충분히 분석했는가? + 1. **White Hat**: Analyzed facts and data sufficiently? - 2. **Red Hat**: 감정과 직관을 고려했는가? + 2. **Red Hat**: Considered emotions and intuition? - 3. **Black Hat**: 위험과 문제점을 검토했는가? + 3. **Black Hat**: Reviewed risks and problems? - 4. **Yellow Hat**: 긍정적 측면을 탐색했는가? + 4. **Yellow Hat**: Explored positive aspects? - 5. **Green Hat**: 창의적 대안을 모색했는가? + 5. **Green Hat**: Sought creative alternatives? - 6. **Blue Hat**: 전체를 통합했는가? + 6. **Blue Hat**: Integrated the whole? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 6가지 관점 모두 깊이 있게 분석 및 통합 + - 5 points: Deeply analyzed and integrated all 6 perspectives - - 4점: 5가지 이상 관점 고려 + - 4 points: Considered 5+ perspectives - - 3점: 3-4가지 관점 고려 + - 3 points: Considered 3-4 perspectives - - 2점: 1-2가지 관점만 고려 + - 2 points: Considered only 1-2 perspectives - - 1점: 단일 관점만 존재 + - 1 points: Single perspective only ' scoring: min: 1 max: 5 criteria: - 5: 6가지 관점 깊이 분석 및 통합 - 4: 5가지+ 관점 - 3: 3-4가지 관점 - 2: 1-2가지 관점 - 1: 단일 관점만 + 5: 6 perspectives deep analysis & integration + 4: 5+ perspectives + 3: 3-4 perspectives + 2: 1-2 perspectives + 1: Single perspective outputSchema: score: number whiteHat: string diff --git a/backend/app/techniques/definitions/cellar/synthesis-framework.yaml b/backend/app/techniques/definitions/cellar/synthesis-framework.yaml index cef8935..98be02d 100644 --- a/backend/app/techniques/definitions/cellar/synthesis-framework.yaml +++ b/backend/app/techniques/definitions/cellar/synthesis-framework.yaml @@ -1,6 +1,5 @@ id: synthesis-framework name: Synthesis Framework -nameKo: 종합 프레임워크 category: cellar applicableHats: - blue @@ -9,52 +8,50 @@ evaluationDimensions: - B2 - D1 - D3 -description: '테제-안티테제-신테제의 변증법적 사고나 +description: 'Technique to integrate various inputs into a single conclusion using dialectical thinking (Thesis-Antithesis-Synthesis). - 다양한 입력을 하나의 결론으로 통합하는 기법. - - 상반된 요소들을 조화시킵니다. + Harmonizes conflicting elements. ' -promptTemplate: '## Synthesis Framework 분석 +promptTemplate: '## Synthesis Framework Analysis - 프로젝트가 다양한 요소를 효과적으로 종합했는지 분석하세요. + Analyze if the project effectively synthesized various elements. - ### 분석 관점: + ### Analysis Perspectives: - 1. **요소 수집**: 다양한 입력/의견을 수집했는가? + 1. **Element Collection**: Were various inputs/opinions collected? - 2. **통합 프레임워크**: 통합을 위한 구조가 있는가? + 2. **Integration Framework**: Is there a structure for integration? - 3. **균형점 발견**: 상충 요소의 균형점을 찾았는가? + 3. **Balance Point**: Was a balance point found for conflicting elements? - 4. **종합 결론**: 통합된 결론/방향이 있는가? + 4. **Synthesized Conclusion**: Is there an integrated conclusion/direction? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 체계적 종합 프레임워크, 명확한 통합 결론 + - 5 points: Systematic synthesis framework, clear integrated conclusion - - 4점: 효과적인 요소 통합 + - 4 points: Effective element integration - - 3점: 일부 요소 종합 + - 3 points: Some elements synthesized - - 2점: 요소 나열만 + - 2 points: Elements listed only - - 1점: 종합 없음 + - 1 points: No synthesis ' scoring: min: 1 max: 5 criteria: - 5: 체계적 프레임워크, 통합 결론 - 4: 효과적 요소 통합 - 3: 일부 요소 종합 - 2: 요소 나열만 - 1: 종합 없음 + 5: Systematic framework, integrated conclusion + 4: Effective integration + 3: Some synthesis + 2: Elements listed only + 1: No synthesis outputSchema: score: number inputElements: string[] diff --git a/backend/app/techniques/definitions/finish/alien-anthropologist.yaml b/backend/app/techniques/definitions/finish/alien-anthropologist.yaml index d8a166c..e95cdce 100644 --- a/backend/app/techniques/definitions/finish/alien-anthropologist.yaml +++ b/backend/app/techniques/definitions/finish/alien-anthropologist.yaml @@ -1,6 +1,5 @@ id: alien-anthropologist name: Alien Anthropologist -nameKo: 외계인 인류학자 category: finish applicableHats: - white @@ -9,52 +8,50 @@ evaluationDimensions: - A1 - C1 - D1 -description: '완전한 외부인(외계인)의 시선으로 상황을 관찰하는 기법. +description: 'Technique to observe situations from the perspective of a complete outsider (alien). - 당연하게 여기는 것들을 낯설게 보면서 - - 숨겨진 가정과 관행을 발견합니다. + Discovers hidden assumptions and practices by looking at taken-for-granted things strangely. ' -promptTemplate: '## Alien Anthropologist 분석 +promptTemplate: '## Alien Anthropologist Analysis - 프로젝트가 외부인의 신선한 시각으로 문제를 바라보았는지 분석하세요. + Analyze if the project looked at the problem with a fresh outsider perspective. - ### 분석 관점: + ### Analysis Perspectives: - 1. **낯설게 보기**: 당연한 것들에 의문을 제기했는가? + 1. **Making Strange**: Did it question taken-for-granted things? - 2. **문화적 관행 발견**: 숨겨진 관행이나 가정을 발견했는가? + 2. **Cultural Practice Discovery**: Did it discover hidden practices or assumptions? - 3. **순수한 관찰**: 선입견 없이 현상을 관찰했는가? + 3. **Pure Observation**: Did it observe phenomena without prejudice? - 4. **새로운 해석**: 기존과 다른 해석을 시도했는가? + 4. **New Interpretation**: Did it attempt an interpretation different from existing ones? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 근본적 관행에 의문 제기, 혁신적 관점 제시 + - 5 points: Challenged fundamental practices, presented innovative perspective - - 4점: 여러 당연한 가정에 도전 + - 4 points: Challenged several taken-for-granted assumptions - - 3점: 일부 관행에 의문 제기 + - 3 points: Questioned some practices - - 2점: 대부분 기존 시각 유지 + - 2 points: Maintained most existing views - - 1점: 순수한 외부 관점 없음 + - 1 points: No pure outsider perspective ' scoring: min: 1 max: 5 criteria: - 5: 근본적 관행 도전, 혁신적 관점 - 4: 여러 가정에 도전 - 3: 일부 관행에 의문 - 2: 기존 시각 유지 - 1: 외부 관점 없음 + 5: Challenged fundamental practices + 4: Challenged several assumptions + 3: Questioned some practices + 2: Maintained existing views + 1: No outsider perspective outputSchema: score: number takenForGranted: string[] diff --git a/backend/app/techniques/definitions/finish/body-wisdom-dialogue.yaml b/backend/app/techniques/definitions/finish/body-wisdom-dialogue.yaml index a0b1c6e..688685d 100644 --- a/backend/app/techniques/definitions/finish/body-wisdom-dialogue.yaml +++ b/backend/app/techniques/definitions/finish/body-wisdom-dialogue.yaml @@ -1,58 +1,55 @@ id: body-wisdom-dialogue name: Body Wisdom Dialogue -nameKo: 몸의 지혜 대화 category: finish applicableHats: - red evaluationDimensions: - C2 - D3 -description: '신체적 감각과 본능적 반응을 활용하는 기법. +description: 'Technique utilizing physical sensations and instinctive reactions. - 머리로만 생각하지 않고 몸의 반응을 통해 - - 직관적 통찰을 얻습니다. + Gains intuitive insights through body reactions rather than just thinking with the head. ' -promptTemplate: '## Body Wisdom Dialogue 분석 +promptTemplate: '## Body Wisdom Dialogue Analysis - 프로젝트가 신체적/감각적 경험을 고려했는지 분석하세요. + Analyze if the project considered physical/sensory experiences. - ### 분석 관점: + ### Analysis Perspectives: - 1. **감각적 경험**: 시각, 청각, 촉각 등 감각을 고려했는가? + 1. **Sensory Experience**: Did it consider senses like sight, hearing, touch? - 2. **신체적 편안함**: 물리적 편안함/불편함을 고려했는가? + 2. **Physical Comfort**: Did it consider physical comfort/discomfort? - 3. **본능적 반응**: 직관적인 호불호를 탐색했는가? + 3. **Instinctive Reaction**: Did it explore intuitive likes/dislikes? - 4. **체화된 인지**: 몸으로 느끼는 경험을 반영했는가? + 4. **Embodied Cognition**: Did it reflect experiences felt with the body? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다감각적 경험 설계, 신체적 반응 깊이 고려 + - 5 points: Multi-sensory experience design, physical reactions deeply considered - - 4점: 주요 감각적 경험 고려 + - 4 points: Key sensory experiences considered - - 3점: 일부 신체적 측면 고려 + - 3 points: Some physical aspects considered - - 2점: 피상적 언급 + - 2 points: Superficial mention - - 1점: 신체/감각 경험 무시 + - 1 points: Physical/sensory experience ignored ' scoring: min: 1 max: 5 criteria: - 5: 다감각 설계, 신체 반응 고려 - 4: 주요 감각 경험 고려 - 3: 일부 신체적 측면 - 2: 피상적 언급 - 1: 신체/감각 무시 + 5: Multi-sensory design, physical reaction + 4: Key sensory experiences + 3: Some physical aspects + 2: Superficial mention + 1: Physical/sensory ignored outputSchema: score: number sensoryConsiderations: string[] @@ -65,4 +62,4 @@ metadata: requiresWebSearch: false requiresRAG: false source: Somatic Psychology / Embodied Design - requiredSources: either +requiredSources: either diff --git a/backend/app/techniques/definitions/finish/emotional-journey.yaml b/backend/app/techniques/definitions/finish/emotional-journey.yaml index 4f22705..a294cbb 100644 --- a/backend/app/techniques/definitions/finish/emotional-journey.yaml +++ b/backend/app/techniques/definitions/finish/emotional-journey.yaml @@ -1,6 +1,5 @@ id: emotional-journey name: Emotional Journey Mapping -nameKo: 감정 여정 category: finish applicableHats: - red @@ -8,52 +7,50 @@ evaluationDimensions: - A2 - C1 - D3 -description: '사용자가 제품/서비스를 사용하는 과정에서 경험하는 - - 감정의 변화를 추적하고 분석하는 기법. +description: 'Technique to track and analyze emotional changes experienced by users while using the product/service. ' -promptTemplate: '## Emotional Journey Mapping (감정 여정 매핑) +promptTemplate: '## Emotional Journey Mapping Analysis - 사용자가 이 프로젝트를 경험하는 과정에서 느끼는 감정의 흐름을 분석하세요. + Analyze the flow of emotions users feel while experiencing this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **첫 접촉**: 처음 발견했을 때의 감정은? + 1. **First Contact**: Emotion when discovered for the first time? - 2. **온보딩**: 시작하는 과정의 감정은? + 2. **Onboarding**: Emotion during the starting process? - 3. **핵심 경험**: 주요 기능 사용 시 감정은? + 3. **Core Experience**: Emotion when using key functions? - 4. **문제 상황**: 오류나 어려움을 겪을 때 감정은? + 4. **Problem Situation**: Emotion when facing errors or difficulties? - 5. **완료 후**: 사용을 마친 후의 감정은? + 5. **After Completion**: Emotion after finishing use? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 전 과정에서 긍정적 감정 유지, 감동적 순간 있음 + - 5 points: Positive emotion maintained throughout, touching moments exist - - 4점: 대체로 긍정적, 일부 불편한 순간 + - 4 points: Mostly positive, some uncomfortable moments - - 3점: 감정 기복이 있음, 중립적 + - 3 points: Emotional ups and downs, neutral - - 2점: 부정적 감정이 더 많음 + - 2 points: Negative emotions prevail - - 1점: 전반적으로 불쾌하거나 좌절감 + - 1 points: Generally unpleasant or frustrating ' scoring: min: 1 max: 5 criteria: - 5: 전 과정 긍정적, 감동적 순간 - 4: 대체로 긍정적 - 3: 감정 기복, 중립 - 2: 부정적 감정 우세 - 1: 전반적 불쾌/좌절 + 5: Positive throughout, touching moments + 4: Mostly positive + 3: Emotional ups and downs + 2: Negative emotions prevail + 1: Generally unpleasant outputSchema: score: number firstContact: string diff --git a/backend/app/techniques/definitions/finish/empathy-mapping.yaml b/backend/app/techniques/definitions/finish/empathy-mapping.yaml index dcbe03a..e88b04a 100644 --- a/backend/app/techniques/definitions/finish/empathy-mapping.yaml +++ b/backend/app/techniques/definitions/finish/empathy-mapping.yaml @@ -1,6 +1,5 @@ id: empathy-mapping name: Empathy Mapping -nameKo: 공감 지도 category: finish applicableHats: - red @@ -9,52 +8,50 @@ evaluationDimensions: - C1 - C2 - D2 -description: '사용자가 생각하고, 느끼고, 말하고, 행동하는 것을 +description: 'Visualization technique mapping what users Say, Think, Do, and Feel into 4 quadrants. - 4사분면으로 매핑하는 시각화 기법. - - 사용자의 내면과 외면을 깊이 이해합니다. + Deeply understands the user''s inner and outer aspects. ' -promptTemplate: '## Empathy Mapping 분석 +promptTemplate: '## Empathy Mapping Analysis - 프로젝트가 사용자에 대한 깊은 공감을 보여주는지 분석하세요. + Analyze if the project shows deep empathy for users. - ### 분석 관점: + ### Analysis Perspectives: - 1. **Says**: 사용자가 무엇을 말하는지 파악했는가? + 1. **Says**: Identified what users say? - 2. **Thinks**: 사용자가 무엇을 생각하는지 이해했는가? + 2. **Thinks**: Understood what users think? - 3. **Does**: 사용자의 행동을 관찰했는가? + 3. **Does**: Observed user actions? - 4. **Feels**: 사용자의 감정을 파악했는가? + 4. **Feels**: Grasped user emotions? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 4가지 영역 모두 깊이 있게 파악, 숨겨진 니즈 발견 + - 5 points: Deeply grasped all 4 areas, discovered hidden needs - - 4점: 4가지 영역 대부분 파악 + - 4 points: Grasped most of 4 areas - - 3점: 2-3가지 영역 파악 + - 3 points: Grasped 2-3 areas - - 2점: 1가지 영역만 피상적 파악 + - 2 points: Superficial grasp of 1 area - - 1점: 사용자 공감 없음 + - 1 points: No empathy for users ' scoring: min: 1 max: 5 criteria: - 5: 4영역 깊이 파악, 숨겨진 니즈 발견 - 4: 4영역 대부분 파악 - 3: 2-3영역 파악 - 2: 1영역 피상적 파악 - 1: 사용자 공감 없음 + 5: Deep grasp of 4 areas, hidden needs + 4: Grasped most of 4 areas + 3: Grasped 2-3 areas + 2: Superficial grasp 1 area + 1: No empathy outputSchema: score: number says: string[] diff --git a/backend/app/techniques/definitions/finish/first-impression-analysis.yaml b/backend/app/techniques/definitions/finish/first-impression-analysis.yaml index de4387c..ece0dee 100644 --- a/backend/app/techniques/definitions/finish/first-impression-analysis.yaml +++ b/backend/app/techniques/definitions/finish/first-impression-analysis.yaml @@ -1,62 +1,59 @@ id: first-impression-analysis name: First Impression Analysis -nameKo: 첫인상 분석 category: finish applicableHats: - red evaluationDimensions: - A3 - D3 -description: '제출물을 처음 접했을 때의 직관적인 반응과 감정을 분석하는 기법. +description: 'Technique to analyze intuitive reactions and emotions when first encountering the submission. - 논리적 분석 이전에 느껴지는 감성적 인상을 평가하여 - - 사용자 경험의 첫인상 품질을 측정. + Measures the quality of the first impression of UX by evaluating emotional impressions felt before logical analysis. ' -promptTemplate: '## First Impression Analysis (첫인상 분석) +promptTemplate: '## First Impression Analysis - 이 프로젝트의 첫인상을 직관적으로 평가하세요. + Evaluate the first impression of this project intuitively. - 논리적 분석보다 감정적/직관적 반응에 집중하세요. + Focus on emotional/intuitive reactions rather than logical analysis. - ### 분석 관점: + ### Analysis Perspectives: - 1. **시각적 첫인상**: 처음 봤을 때 어떤 느낌인가? + 1. **Visual First Impression**: What is the feeling at first sight? - 2. **감정적 반응**: 흥미, 호기심, 신뢰, 불안 등 어떤 감정이 드는가? + 2. **Emotional Reaction**: What emotions arise (interest, curiosity, trust, anxiety)? - 3. **기억성**: 무엇이 가장 먼저 기억에 남는가? + 3. **Memorability**: What remains in memory first? - 4. **직관적 이해도**: 설명 없이도 무엇인지 파악되는가? + 4. **Intuitive Understanding**: Is it understood without explanation? - 5. **사용 욕구**: 써보고 싶은 마음이 드는가? + 5. **Desire to Use**: Do you feel like using it? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 강렬하고 긍정적인 첫인상, 즉시 사용하고 싶음 + - 5 points: Strong and positive first impression, want to use immediately - - 4점: 긍정적 첫인상, 흥미로움 + - 4 points: Positive first impression, interesting - - 3점: 중립적 첫인상, 특별한 감정 없음 + - 3 points: Neutral first impression, no special emotion - - 2점: 다소 부정적, 복잡하거나 혼란스러움 + - 2 points: Somewhat negative, complex or confusing - - 1점: 부정적 첫인상, 관심이 생기지 않음 + - 1 points: Negative first impression, no interest generated ' scoring: min: 1 max: 5 criteria: - 5: 강렬하고 긍정적인 첫인상 - 4: 긍정적, 흥미로운 첫인상 - 3: 중립적 첫인상 - 2: 다소 부정적/혼란스러운 첫인상 - 1: 부정적 첫인상 + 5: Strong/positive first impression + 4: Positive, interesting + 3: Neutral + 2: Somewhat negative/confusing + 1: Negative, no interest outputSchema: score: number visualImpression: string diff --git a/backend/app/techniques/definitions/finish/gut-check.yaml b/backend/app/techniques/definitions/finish/gut-check.yaml index 09acb8c..fc44fd0 100644 --- a/backend/app/techniques/definitions/finish/gut-check.yaml +++ b/backend/app/techniques/definitions/finish/gut-check.yaml @@ -1,6 +1,5 @@ id: gut-check name: Gut Check -nameKo: 직감 체크 category: finish applicableHats: - red @@ -8,56 +7,54 @@ evaluationDimensions: - A1 - A3 - D3 -description: '논리적 분석을 배제하고 순수한 직관과 본능적 반응으로 +description: 'Technique to evaluate the project with pure intuition and instinct, excluding logical analysis. - 프로젝트를 평가하는 기법. "뭔가 이상하다" 또는 "이건 된다"는 - - 직감적 판단을 포착. + Captures gut feelings like "Something is wrong" or "This will work". ' -promptTemplate: '## Gut Check (직관적 느낌 확인) +promptTemplate: '## Gut Check - 논리적 분석 없이 순수한 직관으로 이 프로젝트를 평가하세요. + Evaluate this project with pure intuition without logical analysis. - "왜"보다 "어떤 느낌"인지에 집중하세요. + Focus on "how it feels" rather than "why". - ### 분석 관점: + ### Analysis Perspectives: - 1. **본능적 반응**: 처음 봤을 때 "이건 된다" vs "뭔가 이상하다"? + 1. **Instinctive Reaction**: "This will work" vs "Something is wrong" at first sight? - 2. **신뢰감**: 이 팀/프로젝트를 믿을 수 있는가? + 2. **Trust**: Can you trust this team/project? - 3. **진정성**: 진심으로 문제를 해결하려는 느낌인가? + 3. **Authenticity**: Does it feel like they genuinely want to solve the problem? - 4. **완성도 느낌**: 대충 만든 것 같은가, 정성을 들인 것 같은가? + 4. **Polish**: Does it feel rough or polished? - 5. **성공 예감**: 이 프로젝트가 성공할 것 같은 느낌인가? + 5. **Success Prediction**: Does it feel like it will succeed? - ### 점수 기준: + ### Scoring Criteria: - - 5점: "이건 무조건 된다"는 강한 긍정적 직감 + - 5 points: Strong positive gut feeling "This will definitely work" - - 4점: "괜찮아 보인다"는 긍정적 느낌 + - 4 points: Positive feeling "Looks good" - - 3점: 특별한 느낌 없음, 중립 + - 3 points: No special feeling, neutral - - 2점: "뭔가 부족하다"는 불안한 느낌 + - 2 points: Anxious feeling "Something is missing" - - 1점: "이건 안 될 것 같다"는 부정적 직감 + - 1 points: Negative gut feeling "This won''t work" ' scoring: min: 1 max: 5 criteria: - 5: 강한 긍정적 직감 - 4: 긍정적 느낌 - 3: 중립적 - 2: 불안한 느낌 - 1: 부정적 직감 + 5: Strong positive gut feeling + 4: Positive feeling + 3: Neutral + 2: Anxious feeling + 1: Negative gut feeling outputSchema: score: number instinctiveReaction: string diff --git a/backend/app/techniques/definitions/finish/inner-child-conference.yaml b/backend/app/techniques/definitions/finish/inner-child-conference.yaml index 01d34a7..0082c82 100644 --- a/backend/app/techniques/definitions/finish/inner-child-conference.yaml +++ b/backend/app/techniques/definitions/finish/inner-child-conference.yaml @@ -1,6 +1,5 @@ id: inner-child-conference name: Inner Child Conference -nameKo: 내면 아이 회의 category: finish applicableHats: - red @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - C2 - D3 -description: '어린이의 순수한 호기심과 상상력으로 문제를 바라보는 기법. +description: 'Technique to view problems with a child''s pure curiosity and imagination. - "왜?"라는 질문을 끊임없이 던지며 - - 창의적이고 자유로운 발상을 합니다. + Constantly asking "Why?" and thinking creatively and freely. ' -promptTemplate: '## Inner Child Conference 분석 +promptTemplate: '## Inner Child Conference Analysis - 프로젝트가 순수한 호기심과 상상력을 발휘했는지 분석하세요. + Analyze if the project exercised pure curiosity and imagination. - ### 분석 관점: + ### Analysis Perspectives: - 1. **순수한 호기심**: "왜?"라는 근본적 질문을 던졌는가? + 1. **Pure Curiosity**: Did it ask fundamental questions like "Why?"? - 2. **상상력**: 제약 없는 상상을 했는가? + 2. **Imagination**: Did it imagine without constraints? - 3. **유희성**: 재미있고 놀이 같은 접근이 있었는가? + 3. **Playfulness**: Was there a fun, play-like approach? - 4. **직관적 단순함**: 복잡함을 단순하게 풀었는가? + 4. **Intuitive Simplicity**: Did it solve complexity simply? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 순수한 호기심으로 혁신적 발상, 유희적 접근 + - 5 points: Innovative ideas via pure curiosity, playful approach - - 4점: 자유로운 상상력 발휘 + - 4 points: Free imagination exercised - - 3점: 일부 창의적 시도 + - 3 points: Some creative attempts - - 2점: 대부분 관습적 사고 + - 2 points: Mostly conventional thinking - - 1점: 순수한 호기심/상상력 없음 + - 1 points: No pure curiosity/imagination ' scoring: min: 1 max: 5 criteria: - 5: 순수 호기심, 혁신 발상, 유희적 - 4: 자유로운 상상력 - 3: 일부 창의적 시도 - 2: 관습적 사고 - 1: 호기심/상상력 없음 + 5: Pure curiosity, innovative, playful + 4: Free imagination + 3: Some creative attempts + 2: Conventional thinking + 1: No curiosity/imagination outputSchema: score: number curiousQuestions: string[] diff --git a/backend/app/techniques/definitions/finish/jobs-to-be-done.yaml b/backend/app/techniques/definitions/finish/jobs-to-be-done.yaml index 857914c..53e1567 100644 --- a/backend/app/techniques/definitions/finish/jobs-to-be-done.yaml +++ b/backend/app/techniques/definitions/finish/jobs-to-be-done.yaml @@ -1,6 +1,5 @@ id: jobs-to-be-done name: Jobs to Be Done -nameKo: 고객 과업 이론 category: finish applicableHats: - red @@ -10,54 +9,52 @@ evaluationDimensions: - A2 - A3 - A4 -description: 'Clayton Christensen(Harvard Business School)이 정립한 혁신 이론. +description: 'Innovation theory established by Clayton Christensen (Harvard Business School). - 고객이 제품을 "고용"하여 수행하려는 근본적인 과업(Job)을 이해하고, - - 그 과업을 더 잘 수행할 수 있도록 돕는 솔루션을 설계하는 프레임워크. + Framework to understand the fundamental Job the customer is trying to solve by "hiring" the product, and designing a solution to help perform that Job better. ' -promptTemplate: '## Jobs to Be Done 분석 +promptTemplate: '## Jobs to Be Done Analysis - 이 프로젝트가 고객의 진정한 ''과업(Job)''을 이해하고 해결하는지 분석하세요. + Analyze if this project understands and solves the customer''s true ''Job''. - ### JTBD 핵심 질문: + ### JTBD Key Questions: - 1. **기능적 과업**: 고객이 달성하려는 실질적 목표는 무엇인가? + 1. **Functional Job**: What practical goal is the customer trying to achieve? - 2. **감정적 과업**: 고객이 느끼고 싶은 감정은 무엇인가? + 2. **Emotional Job**: What emotion does the customer want to feel? - 3. **사회적 과업**: 고객이 타인에게 보이고 싶은 모습은? + 3. **Social Job**: How does the customer want to be seen by others? - 4. **고용 상황**: 어떤 상황에서 이 솔루션을 "고용"하는가? + 4. **Hiring Context**: In what situation do they "hire" this solution? - 5. **경쟁 대안**: 현재 이 과업을 해결하는 대안은 무엇인가? + 5. **Competing Alternatives**: What are the alternatives currently solving this Job? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 3가지 과업 모두 명확히 정의, 고용 상황 구체화 + - 5 points: All 3 jobs clearly defined, hiring context concretized - - 4점: 기능+감정 과업 이해, 경쟁 대안 분석 + - 4 points: Functional+Emotional jobs understood, competition analyzed - - 3점: 기능적 과업 명확히 정의 + - 3 points: Functional job clearly defined - - 2점: 암묵적 과업 이해 + - 2 points: Implicit understanding of job - - 1점: 고객 과업 분석 없음 + - 1 points: No customer job analysis ' scoring: min: 1 max: 5 criteria: - 5: 3가지 과업 정의, 고용 상황 구체화 - 4: 기능+감정 이해, 경쟁 분석 - 3: 기능적 과업 명확 정의 - 2: 암묵적 과업 이해 - 1: 고객 과업 분석 없음 + 5: 3 jobs defined, context concrete + 4: Functional+Emotional understood + 3: Functional job defined + 2: Implicit understanding + 1: No job analysis outputSchema: score: number functionalJob: string @@ -72,5 +69,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Clayton Christensen, Harvard Business School - academicReference: 86% 신제품 성공률 문서화, 'Competing Against Luck' (2016) + academicReference: Documented 86% new product success rate, 'Competing Against Luck' (2016) requiredSources: both diff --git a/backend/app/techniques/definitions/finish/kano-model.yaml b/backend/app/techniques/definitions/finish/kano-model.yaml index 611ce25..222c560 100644 --- a/backend/app/techniques/definitions/finish/kano-model.yaml +++ b/backend/app/techniques/definitions/finish/kano-model.yaml @@ -1,6 +1,5 @@ id: kano-model name: Kano Model -nameKo: 카노 모델 category: finish applicableHats: - red @@ -10,56 +9,52 @@ evaluationDimensions: - A2 - A3 - B1 -description: 'Dr. Noriaki Kano(Tokyo University, 1984)가 개발한 고객 만족도 분류 모델. +description: 'Customer satisfaction classification model developed by Dr. Noriaki Kano (Tokyo University, 1984). - 제품 기능을 필수 요소(Must-be), 성능 요소(One-dimensional), - - 매력 요소(Attractive), 무관심(Indifferent), 역효과(Reverse)로 분류하여 - - 우선순위를 결정하는 품질 관리 프레임워크. + Quality management framework classifying product features into Must-be, One-dimensional, Attractive, Indifferent, and Reverse to determine priorities. ' -promptTemplate: '## Kano Model 분석 +promptTemplate: '## Kano Model Analysis - 이 프로젝트가 카노 모델 관점에서 기능을 분류하고 우선순위를 정했는지 분석하세요. + Analyze if this project classified features and set priorities from the Kano Model perspective. - ### Kano 5가지 품질 요소: + ### Kano 5 Quality Elements: - 1. **Must-be (당연품질)**: 없으면 불만, 있어도 만족 증가 없음 + 1. **Must-be**: Dissatisfied if absent, no satisfaction increase if present - 2. **One-dimensional (일원품질)**: 많을수록 만족 증가 + 2. **One-dimensional**: Satisfaction increases as functionality increases - 3. **Attractive (매력품질)**: 없어도 불만 없음, 있으면 크게 만족 + 3. **Attractive**: No dissatisfaction if absent, great satisfaction if present - 4. **Indifferent (무관심)**: 있든 없든 상관없는 기능 + 4. **Indifferent**: Feature that doesn''t matter either way - 5. **Reverse (역품질)**: 있으면 오히려 불만족 + 5. **Reverse**: Dissatisfaction if present - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5가지 분류 명확, 우선순위 최적화, 매력품질 강점 + - 5 points: 5 classifications clear, priority optimized, strong Attractive quality - - 4점: 3-4가지 분류, 필수품질 충족, 매력품질 보유 + - 4 points: 3-4 classifications, Must-be met, Attractive quality present - - 3점: 필수품질과 일원품질 구분 + - 3 points: Distinguished Must-be and One-dimensional - - 2점: 기능 나열만, 분류 없음 + - 2 points: Feature listing only, no classification - - 1점: 기능 우선순위 미고려 + - 1 points: Priorities not considered ' scoring: min: 1 max: 5 criteria: - 5: 5가지 분류, 우선순위 최적화 - 4: 3-4가지 분류, 매력품질 보유 - 3: 필수품질+일원품질 구분 - 2: 기능 나열만 - 1: 우선순위 미고려 + 5: 5 classifications, priority optimized + 4: 3-4 classifications, Attractive present + 3: Must-be + One-dimensional + 2: Listing only + 1: Priorities not considered outputSchema: score: number mustBeFeatures: string[] @@ -75,5 +70,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Dr. Noriaki Kano, Tokyo University (1984) - academicReference: ISO 표준 참조, 글로벌 QFD 적용 + academicReference: ISO standard reference, Global QFD application requiredSources: both diff --git a/backend/app/techniques/definitions/finish/persona-journey.yaml b/backend/app/techniques/definitions/finish/persona-journey.yaml index 6120439..efd3ec5 100644 --- a/backend/app/techniques/definitions/finish/persona-journey.yaml +++ b/backend/app/techniques/definitions/finish/persona-journey.yaml @@ -1,6 +1,5 @@ id: persona-journey name: Persona Journey Mapping -nameKo: 페르소나 여정 category: finish applicableHats: - red @@ -11,52 +10,50 @@ evaluationDimensions: - C2 - C3 - D2 -description: '구체적인 사용자 페르소나를 정의하고, +description: 'Technique to define concrete user personas and map their experience journey step by step. - 그들의 경험 여정을 단계별로 매핑하는 기법. - - 터치포인트, 감정, 니즈를 시각화합니다. + Visualizes touchpoints, emotions, and needs. ' -promptTemplate: '## Persona Journey Mapping 분석 +promptTemplate: '## Persona Journey Mapping Analysis - 프로젝트가 사용자 페르소나와 여정을 어떻게 정의했는지 분석하세요. + Analyze how the project defined user personas and journeys. - ### 분석 관점: + ### Analysis Perspectives: - 1. **페르소나 구체성**: 상세한 사용자 프로필이 있는가? + 1. **Persona Concreteness**: Is there a detailed user profile? - 2. **여정 단계**: 사용자 경험의 단계가 명확히 정의되었는가? + 2. **Journey Stages**: Are user experience stages clearly defined? - 3. **감정 곡선**: 각 단계에서의 감정이 고려되었는가? + 3. **Emotional Curve**: Are emotions at each stage considered? - 4. **Pain Points**: 문제점과 개선 기회가 식별되었는가? + 4. **Pain Points**: Have problems and improvement opportunities been identified? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다중 페르소나, 상세 여정, 감정 곡선, 개선점 도출 + - 5 points: Multiple personas, detailed journey, emotional curve, improvements identified - - 4점: 명확한 페르소나와 여정 단계 + - 4 points: Clear persona and journey stages - - 3점: 기본 페르소나 정의 + - 3 points: Basic persona definition - - 2점: 타겟 사용자 언급만 + - 2 points: Target user mentioned only - - 1점: 사용자 정의 없음 + - 1 points: No user definition ' scoring: min: 1 max: 5 criteria: - 5: 다중 페르소나, 상세 여정, 감정 곡선 - 4: 명확한 페르소나와 여정 - 3: 기본 페르소나 정의 - 2: 타겟 사용자 언급만 - 1: 사용자 정의 없음 + 5: Multiple personas, detailed journey + 4: Clear persona and journey + 3: Basic persona definition + 2: Target user mentioned + 1: No user definition outputSchema: score: number personasIdentified: string[] diff --git a/backend/app/techniques/definitions/finish/role-playing.yaml b/backend/app/techniques/definitions/finish/role-playing.yaml index 39e864c..b4aef4f 100644 --- a/backend/app/techniques/definitions/finish/role-playing.yaml +++ b/backend/app/techniques/definitions/finish/role-playing.yaml @@ -1,6 +1,5 @@ id: role-playing name: Role Playing -nameKo: 역할극 category: finish applicableHats: - red @@ -9,52 +8,50 @@ evaluationDimensions: - C1 - C2 - D2 -description: '실제 사용자의 입장에서 제품/서비스를 경험해보는 기법. +description: 'Technique to experience the product/service from the perspective of an actual user. - 사용자의 행동, 감정, 니즈를 직접 체험함으로써 - - 더 깊은 공감과 통찰을 얻습니다. + Gains deeper empathy and insight by directly experiencing user actions, emotions, and needs. ' -promptTemplate: '## Role Playing 분석 +promptTemplate: '## Role Playing Analysis - 프로젝트 팀이 사용자 역할을 얼마나 깊이 체험했는지 분석하세요. + Analyze how deeply the project team experienced the user role. - ### 분석 관점: + ### Analysis Perspectives: - 1. **역할 정의**: 구체적인 사용자 역할을 정의했는가? + 1. **Role Definition**: Was a concrete user role defined? - 2. **상황 설정**: 사용 상황을 구체적으로 설정했는가? + 2. **Situation Setting**: Was the usage situation concretely set? - 3. **체험 깊이**: 실제로 사용자 입장에서 경험해 보았는가? + 3. **Experience Depth**: Did they actually experience it from the user''s perspective? - 4. **인사이트 도출**: 역할극에서 의미 있는 발견이 있었는가? + 4. **Insight Derivation**: Were meaningful discoveries made from the role play? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다양한 사용자 역할을 깊이 체험하고 핵심 인사이트 발견 + - 5 points: Deeply experienced various roles and discovered core insights - - 4점: 주요 사용자 역할을 체험하고 인사이트 도출 + - 4 points: Experienced key roles and derived insights - - 3점: 기본적인 사용자 관점 고려 + - 3 points: Considered basic user perspective - - 2점: 피상적인 사용자 언급 + - 2 points: Superficial user mention - - 1점: 사용자 관점 고려 없음 + - 1 points: No user perspective ' scoring: min: 1 max: 5 criteria: - 5: 다양한 역할 깊이 체험, 핵심 인사이트 - 4: 주요 역할 체험 및 인사이트 - 3: 기본적 사용자 관점 고려 - 2: 피상적 사용자 언급 - 1: 사용자 관점 없음 + 5: Deep experience, core insights + 4: Key roles experienced + 3: Basic user perspective + 2: Superficial mention + 1: No user perspective outputSchema: score: number rolesExplored: string[] diff --git a/backend/app/techniques/definitions/finish/sensory-exploration.yaml b/backend/app/techniques/definitions/finish/sensory-exploration.yaml index a00f754..6efd0a1 100644 --- a/backend/app/techniques/definitions/finish/sensory-exploration.yaml +++ b/backend/app/techniques/definitions/finish/sensory-exploration.yaml @@ -1,6 +1,5 @@ id: sensory-exploration name: Sensory Exploration -nameKo: 감각 탐험 category: finish applicableHats: - red @@ -8,52 +7,50 @@ evaluationDimensions: - C2 - D2 - D3 -description: '오감(시각, 청각, 촉각, 후각, 미각)을 통해 +description: 'Technique to explore and design experiences through the five senses (sight, hearing, touch, smell, taste). - 경험을 탐색하고 설계하는 기법. - - 다감각적 경험의 풍부함을 추구합니다. + Pursues richness of multi-sensory experience. ' -promptTemplate: '## Sensory Exploration 분석 +promptTemplate: '## Sensory Exploration Analysis - 프로젝트가 다양한 감각적 경험을 탐색했는지 분석하세요. + Analyze if the project explored various sensory experiences. - ### 분석 관점: + ### Analysis Perspectives: - 1. **시각적 경험**: 보는 경험을 어떻게 설계했는가? + 1. **Visual Experience**: How was the viewing experience designed? - 2. **청각적 경험**: 소리/사운드를 고려했는가? + 2. **Auditory Experience**: Was sound considered? - 3. **촉각/물리적 경험**: 만지고 조작하는 경험은? + 3. **Tactile/Physical Experience**: What is the experience of touching and manipulating? - 4. **다감각 통합**: 여러 감각의 조화를 고려했는가? + 4. **Multi-sensory Integration**: Was the harmony of multiple senses considered? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5감 모두 고려한 통합적 감각 경험 설계 + - 5 points: Integrated sensory experience design considering all 5 senses - - 4점: 3가지 이상 감각 고려 + - 4 points: 3+ senses considered - - 3점: 시각 외 1가지 감각 추가 고려 + - 3 points: Sight + 1 other sense considered - - 2점: 시각적 경험만 고려 + - 2 points: Visual experience only - - 1점: 감각적 경험 고려 없음 + - 1 points: Sensory experience not considered ' scoring: min: 1 max: 5 criteria: - 5: 5감 통합 경험 설계 - 4: 3가지+ 감각 고려 - 3: 시각 + 1가지 감각 - 2: 시각만 고려 - 1: 감각 경험 무고려 + 5: 5-sense integrated design + 4: 3+ senses considered + 3: Sight + 1 sense + 2: Visual only + 1: Sensory not considered outputSchema: score: number visualDesign: string diff --git a/backend/app/techniques/definitions/palate/analogical-thinking.yaml b/backend/app/techniques/definitions/palate/analogical-thinking.yaml index 6ef6943..5875091 100644 --- a/backend/app/techniques/definitions/palate/analogical-thinking.yaml +++ b/backend/app/techniques/definitions/palate/analogical-thinking.yaml @@ -1,6 +1,5 @@ id: analogical-thinking name: Analogical Thinking -nameKo: 유추적 사고 category: palate applicableHats: - green @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - A3 - B2 -description: '유사한 상황이나 문제에서 패턴을 찾아 +description: 'Thinking method to find patterns in similar situations or problems and apply them to the current problem. - 현재 문제에 적용하는 사고 방식. - - "X는 Y와 같다"의 형태로 새로운 통찰을 얻습니다. + Gains new insights in the form of ''X is like Y''. ' -promptTemplate: '## Analogical Thinking 분석 +promptTemplate: '## Analogical Thinking Analysis - 이 프로젝트에서 유추적 사고의 흔적을 분석하세요. + Analyze traces of analogical thinking in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **유추 발견**: 다른 영역의 유사한 문제/해결책을 참조했는가? + 1. **Analogy Discovery**: Did it reference similar problems/solutions in other domains? - 2. **패턴 추출**: 유사 사례에서 공통 패턴을 추출했는가? + 2. **Pattern Extraction**: Did it extract common patterns from similar cases? - 3. **적용 품질**: 유추가 현재 문제에 적절히 적용되었는가? + 3. **Application Quality**: Was the analogy appropriately applied to the current problem? - 4. **통찰 깊이**: 유추를 통해 얻은 통찰이 깊이 있는가? + 4. **Insight Depth**: Is the insight gained through analogy deep? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 깊은 구조적 유추로 핵심 해결책 도출 + - 5 points: Core solution derived from deep structural analogy - - 4점: 효과적인 유추로 새로운 접근법 발견 + - 4 points: New approach discovered through effective analogy - - 3점: 유추를 활용하나 표면적 수준 + - 3 points: Uses analogy but at a surface level - - 2점: 피상적인 비교만 존재 + - 2 points: Only superficial comparison exists - - 1점: 유추적 사고 흔적 없음 + - 1 points: No trace of analogical thinking ' scoring: min: 1 max: 5 criteria: - 5: 깊은 구조적 유추로 핵심 해결책 - 4: 효과적인 유추로 새로운 접근 - 3: 표면적 유추 활용 - 2: 피상적 비교만 존재 - 1: 유추적 사고 없음 + 5: Core solution via deep structural analogy + 4: New approach via effective analogy + 3: Surface level analogy + 2: Superficial comparison only + 1: No analogical thinking outputSchema: score: number analogiesFound: string[] diff --git a/backend/app/techniques/definitions/palate/biomimicry.yaml b/backend/app/techniques/definitions/palate/biomimicry.yaml index 630770b..116be24 100644 --- a/backend/app/techniques/definitions/palate/biomimicry.yaml +++ b/backend/app/techniques/definitions/palate/biomimicry.yaml @@ -1,6 +1,5 @@ id: biomimicry name: Biomimicry -nameKo: 생체모방 category: palate applicableHats: - green @@ -8,52 +7,50 @@ evaluationDimensions: - A3 - B1 - B2 -description: '자연의 디자인과 프로세스에서 영감을 얻어 +description: 'A technique to solve problems by getting inspiration from nature''s designs and processes. - 문제를 해결하는 기법. - - 38억 년 진화의 지혜를 활용합니다. + Utilizes the wisdom of 3.8 billion years of evolution. ' -promptTemplate: '## Biomimicry 분석 +promptTemplate: '## Biomimicry Analysis - 이 프로젝트가 자연에서 영감을 받았는지 분석하세요. + Analyze if the project was inspired by nature. - ### 분석 관점: + ### Analysis Perspectives: - 1. **자연 모방**: 자연의 디자인이나 프로세스를 모방했는가? + 1. **Nature Mimicry**: Did it mimic nature''s designs or processes? - 2. **생물학적 영감**: 생물의 특성에서 아이디어를 얻었는가? + 2. **Biological Inspiration**: Did it get ideas from biological characteristics? - 3. **생태계 원리**: 생태계의 원리(순환, 적응 등)를 적용했는가? + 3. **Ecosystem Principles**: Did it apply ecosystem principles (circulation, adaptation, etc.)? - 4. **지속가능성**: 자연의 지속가능한 방식을 참고했는가? + 4. **Sustainability**: Did it reference nature''s sustainable methods? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 자연의 원리를 핵심 솔루션에 깊이 적용 + - 5 points: Principles of nature deeply applied to core solution - - 4점: 명확한 생체모방 요소가 설계에 반영 + - 4 points: Clear biomimicry elements reflected in design - - 3점: 부분적으로 자연에서 영감 + - 3 points: Partially inspired by nature - - 2점: 자연 참조가 피상적 + - 2 points: Nature reference is superficial - - 1점: 생체모방 요소 없음 + - 1 points: No biomimicry elements ' scoring: min: 1 max: 5 criteria: - 5: 자연 원리를 핵심에 깊이 적용 - 4: 명확한 생체모방 요소 반영 - 3: 부분적 자연 영감 - 2: 피상적 자연 참조 - 1: 생체모방 요소 없음 + 5: Nature principles deeply applied + 4: Clear biomimicry elements + 3: Partially inspired by nature + 2: Superficial nature reference + 1: No biomimicry elements outputSchema: score: number natureInspiration: string[] diff --git a/backend/app/techniques/definitions/palate/concept-blending.yaml b/backend/app/techniques/definitions/palate/concept-blending.yaml index 8ecf5a4..0abba3d 100644 --- a/backend/app/techniques/definitions/palate/concept-blending.yaml +++ b/backend/app/techniques/definitions/palate/concept-blending.yaml @@ -1,58 +1,55 @@ id: concept-blending name: Concept Blending -nameKo: 개념 블렌딩 category: palate applicableHats: - green evaluationDimensions: - A3 - B1 -description: 'Fauconnier & Turner의 개념 혼합 이론. +description: 'Concept Blending Theory by Fauconnier & Turner. - 서로 다른 도메인의 개념들을 융합하여 - - 새로운 창발적 의미를 생성합니다. + Fuses concepts from different domains to generate new emergent meanings. ' -promptTemplate: '## Concept Blending 분석 +promptTemplate: '## Concept Blending Analysis - 이 프로젝트에서 서로 다른 개념들의 창의적 융합이 있는지 분석하세요. + Analyze if there is creative fusion of different concepts in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **입력 공간 식별**: 어떤 도메인/개념들이 결합되었는가? + 1. **Input Space Identification**: What domains/concepts were combined? - 2. **총칭 공간**: 결합된 개념들의 공통 추상 구조는? + 2. **Generic Space**: What is the common abstract structure of the combined concepts? - 3. **혼합 공간**: 창발적 구조(emergent structure)가 생성되었는가? + 3. **Blended Space**: Has an emergent structure been created? - 4. **새로운 의미**: 입력 공간에 없던 새로운 의미가 생겼는가? + 4. **New Meaning**: Has a new meaning not present in the input spaces emerged? - ### 점수 기준: + ### Scoring Criteria: - - 5점: "Land yacht"처럼 완전히 새로운 카테고리 창출 + - 5 points: Creates a completely new category like "Land yacht" - - 4점: 2개 이상 도메인의 명확한 창발적 융합 + - 4 points: Clear emergent fusion of 2+ domains - - 3점: 관련 분야 간 의미 있는 조합 + - 3 points: Meaningful combination between related fields - - 2점: 동일 분야 내 기능 조합 + - 2 points: Combination of functions within the same field - - 1점: 단일 개념 적용, 혼합 없음 + - 1 points: Single concept applied, no blending ' scoring: min: 1 max: 5 criteria: - 5: 완전히 새로운 카테고리 창출 - 4: 2개+ 도메인의 창발적 융합 - 3: 관련 분야 간 의미 있는 조합 - 2: 동일 분야 내 기능 조합 - 1: 단일 개념 적용 + 5: Creates completely new category + 4: Emergent fusion of 2+ domains + 3: Meaningful combination of related fields + 2: Function combination in same field + 1: Single concept application outputSchema: score: number inputSpaces: string[] diff --git a/backend/app/techniques/definitions/palate/cross-pollination.yaml b/backend/app/techniques/definitions/palate/cross-pollination.yaml index 14bfc5e..d3a6308 100644 --- a/backend/app/techniques/definitions/palate/cross-pollination.yaml +++ b/backend/app/techniques/definitions/palate/cross-pollination.yaml @@ -1,6 +1,5 @@ id: cross-pollination name: Cross-Pollination -nameKo: 교차 수분 category: palate applicableHats: - green @@ -9,57 +8,54 @@ evaluationDimensions: - A3 - B1 - B2 -description: '다른 산업이나 분야의 아이디어를 +description: 'Technique to apply ideas from other industries or fields to the current problem. - 현재 문제에 적용하는 기법. - - IDEO에서 자주 활용하는 혁신 방법론. + Innovation methodology frequently used by IDEO. ' -promptTemplate: '## Cross-Pollination 분석 +promptTemplate: '## Cross-Pollination Analysis - 이 프로젝트가 다른 분야에서 영감을 가져왔는지 분석하세요. + Analyze if this project brought inspiration from other fields. - ### 분석 관점: + ### Analysis Perspectives: - 1. **외부 영감**: 다른 산업/분야에서 가져온 아이디어는? + 1. **External Inspiration**: Ideas taken from other industries/fields? - 2. **적용 방식**: 다른 분야의 해결책을 어떻게 적용했는가? + 2. **Application Method**: How were solutions from other fields applied? - 3. **유사성 발견**: 다른 분야의 문제와 유사점을 발견했는가? + 3. **Similarity Discovery**: Did it find similarities with problems in other fields? - 4. **이전 가치**: 외부 아이디어가 얼마나 효과적으로 이전되었는가? + 4. **Transfer Value**: How effectively was the external idea transferred? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전히 다른 산업의 솔루션을 효과적으로 적용 + - 5 points: Effectively applied solutions from completely different industries - - 4점: 관련 없는 분야에서 명확한 영감 + - 4 points: Clear inspiration from unrelated fields - - 3점: 인접 분야 참조 + - 3 points: Referenced adjacent fields - - 2점: 동일 산업 내 벤치마킹 + - 2 points: Benchmarking within the same industry - - 1점: 외부 참조 없음 + - 1 points: No external reference ' scoring: min: 1 max: 5 criteria: - 5: 다른 산업 솔루션의 효과적 적용 - 4: 관련 없는 분야에서 명확한 영감 - 3: 인접 분야 참조 - 2: 동일 산업 내 벤치마킹 - 1: 외부 참조 없음 + 5: Effective application from different industry + 4: Clear inspiration from unrelated fields + 3: Adjacent field reference + 2: Same industry benchmarking + 1: No external reference outputSchema: score: number externalSources: string[] applicationMethod: string - similarityDiscovery: string transferValue: string reasoning: string metadata: diff --git a/backend/app/techniques/definitions/palate/design-thinking.yaml b/backend/app/techniques/definitions/palate/design-thinking.yaml index b62c819..5257a1e 100644 --- a/backend/app/techniques/definitions/palate/design-thinking.yaml +++ b/backend/app/techniques/definitions/palate/design-thinking.yaml @@ -1,6 +1,5 @@ id: design-thinking name: Design Thinking -nameKo: 디자인 씽킹 category: palate applicableHats: - green @@ -10,54 +9,52 @@ evaluationDimensions: - A2 - A3 - B1 -description: 'Stanford d.school과 IDEO에서 체계화한 인간 중심 혁신 방법론. +description: 'Human-centered innovation methodology systematized by Stanford d.school and IDEO. - 공감(Empathize), 정의(Define), 아이디어(Ideate), 프로토타입(Prototype), - - 테스트(Test) 5단계로 문제를 해결하는 창의적 접근법. + Creative approach solving problems in 5 steps: Empathize, Define, Ideate, Prototype, Test. ' -promptTemplate: '## Design Thinking 분석 +promptTemplate: '## Design Thinking Analysis - 이 프로젝트가 디자인 씽킹 5단계를 얼마나 잘 적용했는지 분석하세요. + Analyze how well this project applied the 5 steps of Design Thinking. - ### Design Thinking 5단계: + ### Design Thinking 5 Steps: - 1. **Empathize (공감)**: 사용자의 니즈와 고통점을 깊이 이해했는가? + 1. **Empathize**: Did it deeply understand user needs and pain points? - 2. **Define (정의)**: 문제를 명확하고 실행 가능한 형태로 정의했는가? + 2. **Define**: Did it define the problem in a clear and actionable form? - 3. **Ideate (아이디어)**: 다양한 해결책을 창의적으로 발상했는가? + 3. **Ideate**: Did it brainstorm various solutions creatively? - 4. **Prototype (프로토타입)**: 빠른 실험을 위한 시제품을 만들었는가? + 4. **Prototype**: Did it make a prototype for quick experimentation? - 5. **Test (테스트)**: 실제 사용자로부터 피드백을 받았는가? + 5. **Test**: Did it receive feedback from actual users? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5단계 모두 명확히 수행, 반복적 개선 사이클 적용 + - 5 points: Clearly performed all 5 steps, applied iterative improvement cycle - - 4점: 4단계 이상 수행, 사용자 피드백 반영 + - 4 points: Performed 4+ steps, reflected user feedback - - 3점: 3단계 수행, 기본적인 사용자 이해 + - 3 points: Performed 3 steps, basic user understanding - - 2점: 1-2단계만 부분적 수행 + - 2 points: Partially performed 1-2 steps - - 1점: 디자인 씽킹 적용 없음 + - 1 points: No application of Design Thinking ' scoring: min: 1 max: 5 criteria: - 5: 5단계 완전 수행, 반복 개선 - 4: 4단계+ 수행, 피드백 반영 - 3: 3단계 수행, 기본 이해 - 2: 1-2단계 부분 수행 - 1: 디자인 씽킹 미적용 + 5: All 5 steps, iterative improvement + 4: 4+ steps, feedback reflected + 3: 3 steps, basic understanding + 2: 1-2 steps partial + 1: No Design Thinking outputSchema: score: number empathizeEvidence: string @@ -73,5 +70,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: David Kelley, Stanford d.school (2005) / IDEO - academicReference: Stanford 정규 커리큘럼, IDEO Human-Centered Design + academicReference: Stanford regular curriculum, IDEO Human-Centered Design requiredSources: both diff --git a/backend/app/techniques/definitions/palate/first-principles-thinking.yaml b/backend/app/techniques/definitions/palate/first-principles-thinking.yaml index 79d27e0..1adee81 100644 --- a/backend/app/techniques/definitions/palate/first-principles-thinking.yaml +++ b/backend/app/techniques/definitions/palate/first-principles-thinking.yaml @@ -1,6 +1,5 @@ id: first-principles-thinking name: First Principles Thinking -nameKo: 제1원칙 사고 category: palate applicableHats: - green @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - B1 - B2 -description: '기존의 가정과 관행을 근본적으로 분해하고, +description: 'Thinking technique to fundamentally disassemble existing assumptions and practices and rebuild from basic principles. - 기본 원리에서부터 새롭게 재구축하는 사고 기법. - - Elon Musk가 SpaceX, Tesla에서 활용한 것으로 유명. + Famous for being used by Elon Musk at SpaceX and Tesla. ' -promptTemplate: '## First Principles Thinking 분석 +promptTemplate: '## First Principles Thinking Analysis - 이 프로젝트가 기존 가정을 어떻게 도전하고 재구축했는지 분석하세요. + Analyze how this project challenged and rebuilt existing assumptions. - ### 분석 관점: + ### Analysis Perspectives: - 1. **기존 가정 식별**: 이 도메인에서 "당연하다고 여겨지는" 가정들은? + 1. **Identify Existing Assumptions**: What are the assumptions taken for granted in this domain? - 2. **도전 증거**: 팀이 이 가정들에 명시적으로 도전한 증거는? + 2. **Evidence of Challenge**: Is there evidence the team explicitly challenged these assumptions? - 3. **기본 요소 분해**: 문제를 기본 구성요소로 분해한 흔적은? + 3. **Decomposition to Basics**: Are there traces of breaking the problem down to basic components? - 4. **재구축 방식**: 기본 원리에서 새롭게 구축한 부분은? + 4. **Reconstruction Method**: Which parts were newly built from basic principles? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 산업 패러다임 재정의 수준 (예: "배터리팩 가격을 원자재 기준으로 재계산") + - 5 points: Redefined industry paradigm (e.g., "Recalculated battery pack price based on raw materials") - - 4점: 2개 이상 핵심 가정에 도전하고 대안 제시 + - 4 points: Challenged 2+ key assumptions and suggested alternatives - - 3점: 1개 핵심 가정에 도전 + - 3 points: Challenged 1 key assumption - - 2점: 기존 접근에 미미한 변형 + - 2 points: Minor variation to existing approach - - 1점: 기존 솔루션을 그대로 복제 + - 1 points: Copied existing solutions as is ' scoring: min: 1 max: 5 criteria: - 5: 산업 패러다임 재정의 수준 - 4: 2개+ 핵심 가정 도전 및 대안 제시 - 3: 1개 핵심 가정 도전 - 2: 기존 접근에 미미한 변형 - 1: 기존 솔루션 복제 + 5: Redefined industry paradigm + 4: Challenged 2+ key assumptions + 3: Challenged 1 key assumption + 2: Minor variation + 1: Copied existing solution outputSchema: score: number assumptionsChallenged: string[] diff --git a/backend/app/techniques/definitions/palate/lateral-thinking.yaml b/backend/app/techniques/definitions/palate/lateral-thinking.yaml index fb883d4..eb05f01 100644 --- a/backend/app/techniques/definitions/palate/lateral-thinking.yaml +++ b/backend/app/techniques/definitions/palate/lateral-thinking.yaml @@ -1,58 +1,55 @@ id: lateral-thinking name: Lateral Thinking -nameKo: 수평적 사고 category: palate applicableHats: - green evaluationDimensions: - A3 - B2 -description: 'Edward de Bono가 개발한 창의적 문제 해결 방법. +description: 'Creative problem-solving method developed by Edward de Bono. - 논리적/수직적 사고 대신 측면에서 접근하여 - - 새로운 패턴과 관점을 발견합니다. + Approaches from the side instead of logical/vertical thinking to discover new patterns and perspectives. ' -promptTemplate: '## Lateral Thinking 분석 +promptTemplate: '## Lateral Thinking Analysis - 이 프로젝트가 문제에 측면에서 접근한 흔적을 분석하세요. + Analyze traces of approaching the problem from the side in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **패턴 탈피**: 기존 사고 패턴에서 벗어난 접근이 있는가? + 1. **Breaking Patterns**: Is there an approach that deviates from existing thinking patterns? - 2. **대안적 관점**: 문제를 완전히 다른 각도에서 본 흔적은? + 2. **Alternative Perspectives**: Are there traces of viewing the problem from a completely different angle? - 3. **창의적 점프**: 논리적 단계를 건너뛴 창의적 도약이 있는가? + 3. **Creative Jump**: Is there a creative leap skipping logical steps? - 4. **새로운 패턴**: 기존에 없던 새로운 패턴을 만들었는가? + 4. **New Patterns**: Did it create new patterns that didn''t exist before? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전히 새로운 패턴과 접근법 창출 + - 5 points: Created completely new patterns and approaches - - 4점: 명확한 측면 접근으로 새로운 해결책 발견 + - 4 points: Discovered new solutions with clear lateral approach - - 3점: 부분적으로 수평적 사고 적용 + - 3 points: Partially applied lateral thinking - - 2점: 대부분 논리적/수직적 접근 + - 2 points: Mostly logical/vertical approach - - 1점: 전통적인 순차적 사고만 사용 + - 1 points: Used only traditional sequential thinking ' scoring: min: 1 max: 5 criteria: - 5: 완전히 새로운 패턴과 접근법 - 4: 명확한 측면 접근 - 3: 부분적 수평적 사고 - 2: 대부분 수직적 접근 - 1: 전통적 순차적 사고 + 5: Completely new patterns/approaches + 4: Clear lateral approach + 3: Partial lateral thinking + 2: Mostly vertical approach + 1: Traditional sequential thinking outputSchema: score: number patternBreaks: string[] diff --git a/backend/app/techniques/definitions/palate/provocation-technique.yaml b/backend/app/techniques/definitions/palate/provocation-technique.yaml index c8a5322..9610f74 100644 --- a/backend/app/techniques/definitions/palate/provocation-technique.yaml +++ b/backend/app/techniques/definitions/palate/provocation-technique.yaml @@ -1,63 +1,60 @@ id: provocation-technique name: Provocation Technique -nameKo: 도발 기법 category: palate applicableHats: - green evaluationDimensions: - A3 - A4 -description: 'Edward de Bono의 "Po" 기법. +description: 'Edward de Bono''s "Po" technique. - 의도적으로 불합리하거나 도발적인 아이디어를 제시하여 - - 새로운 사고의 방향을 유도합니다. + Intentionally presents unreasonable or provocative ideas to induce new directions of thinking. ' -promptTemplate: '## Provocation Technique (Po) 분석 +promptTemplate: '## Provocation Technique (Po) Analysis - 이 프로젝트에서 도발적이거나 파격적인 아이디어가 있는지 분석하세요. + Analyze if there are provocative or unconventional ideas in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **대담한 아이디어**: 업계에서 "불가능"하다고 여기는 것에 도전했는가? + 1. **Bold Ideas**: Did it challenge what is considered "impossible" in the industry? - 2. **도발적 제안**: 기존 규범을 깨는 제안이 있는가? + 2. **Provocative Suggestions**: Are there proposals that break existing norms? - 3. **창의적 도약**: 점진적 개선이 아닌 급진적 변화를 시도했는가? + 3. **Creative Leap**: Did it attempt radical change rather than incremental improvement? - 4. **Po 수준**: "만약 ~라면?" 수준의 대담함이 있는가? + 4. **Po Level**: Is there boldness at the level of "What if...?"? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 업계 상식을 완전히 뒤엎는 도발적 아이디어 + - 5 points: Provocative idea completely overturning industry common sense - - 4점: 기존 관행에 대한 명확한 도전 + - 4 points: Clear challenge to existing practices - - 3점: 약간의 파격적 요소 포함 + - 3 points: Contains some unconventional elements - - 2점: 안전한 범위 내 개선 + - 2 points: Improvement within safe range - - 1점: 보수적 접근, 도발적 요소 없음 + - 1 points: Conservative approach, no provocative elements ' scoring: min: 1 max: 5 criteria: - 5: 업계 상식을 뒤엎는 도발적 아이디어 - 4: 기존 관행에 대한 명확한 도전 - 3: 약간의 파격적 요소 - 2: 안전한 범위 내 개선 - 1: 보수적 접근 + 5: Overturns industry common sense + 4: Clear challenge to practices + 3: Some unconventional elements + 2: Safe improvement + 1: Conservative approach outputSchema: score: number provocativeIdeas: string[] industryNormsChallenged: string - creativeLeapEvidence: string + creativeleapEvidence: string reasoning: string metadata: complexity: medium diff --git a/backend/app/techniques/definitions/palate/quantum-superposition.yaml b/backend/app/techniques/definitions/palate/quantum-superposition.yaml index 109c261..821f314 100644 --- a/backend/app/techniques/definitions/palate/quantum-superposition.yaml +++ b/backend/app/techniques/definitions/palate/quantum-superposition.yaml @@ -1,6 +1,5 @@ id: quantum-superposition name: Quantum Superposition Thinking -nameKo: 양자 중첩 category: palate applicableHats: - green @@ -8,54 +7,54 @@ applicableHats: evaluationDimensions: - A3 - B4 -description: '양자역학의 중첩 원리에서 영감을 받은 창의적 사고 기법. +description: 'Creative thinking technique inspired by the superposition principle of quantum mechanics. - 상반되는 가능성들을 동시에 유지하며 최적의 해결책을 탐색. + Maintains conflicting possibilities simultaneously to search for the optimal solution. - "이것 또는 저것"이 아닌 "이것과 저것 동시에"를 고려. + Considers "Both This and That" instead of "Either This or That". ' -promptTemplate: '## Quantum Superposition Thinking (양자 중첩 사고) +promptTemplate: '## Quantum Superposition Thinking Analysis - 이 프로젝트가 상반되는 가능성들을 어떻게 다루는지 분석하세요. + Analyze how this project handles conflicting possibilities. - ### 분석 관점: + ### Analysis Perspectives: - 1. **이분법 탈피**: 양자택일 대신 "둘 다"를 선택했는가? + 1. **Escaping Dichotomy**: Did it choose "Both" instead of "Either/Or"? - 2. **모순 통합**: 상충되는 요구사항을 어떻게 해결했는가? + 2. **Integrating Contradictions**: How were conflicting requirements resolved? - 3. **다중 경로**: 여러 가능성을 열어두었는가? + 3. **Multiple Paths**: Were multiple possibilities kept open? - 4. **유연성**: 상황에 따라 적응할 수 있는 구조인가? + 4. **Flexibility**: Is the structure adaptable to situations? - 5. **패러독스 활용**: 역설적 상황을 기회로 활용했는가? + 5. **Utilizing Paradox**: Was a paradoxical situation used as an opportunity? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다중 가능성을 동시에 유지하며 유연하게 대응 + - 5 points: Simultaneously maintains multiple possibilities with flexible response - - 4점: 일부 영역에서 다중 가능성 고려 + - 4 points: Considers multiple possibilities in some areas - - 3점: 2-3개 대안을 검토 + - 3 points: Reviews 2-3 alternatives - - 2점: 단일 경로에 집중, 대안 제한적 + - 2 points: Focuses on a single path, limited alternatives - - 1점: 이분법적 사고, 유연성 없음 + - 1 points: Dichotomous thinking, no flexibility ' scoring: min: 1 max: 5 criteria: - 5: 다중 가능성 동시 유지, 유연한 대응 - 4: 일부 영역에서 다중 가능성 - 3: 2-3개 대안 검토 - 2: 단일 경로 집중 - 1: 이분법적 사고 + 5: Multiple possibilities, flexible response + 4: Multiple possibilities in some areas + 3: Reviews 2-3 alternatives + 2: Single path focus + 1: Dichotomous thinking outputSchema: score: number dichotomyEscape: string diff --git a/backend/app/techniques/definitions/palate/random-stimulation.yaml b/backend/app/techniques/definitions/palate/random-stimulation.yaml index ce24e88..fc5c5d2 100644 --- a/backend/app/techniques/definitions/palate/random-stimulation.yaml +++ b/backend/app/techniques/definitions/palate/random-stimulation.yaml @@ -1,57 +1,54 @@ id: random-stimulation name: Random Stimulation -nameKo: 무작위 자극 category: palate applicableHats: - green evaluationDimensions: - A3 -description: '무작위 단어, 이미지, 개념을 사용하여 +description: 'Technique using random words, images, or concepts to create unexpected connections. - 예상치 못한 연결고리를 만드는 기법. - - 비선형적 아이디어 연결을 유도합니다. + Induces non-linear idea connections. ' -promptTemplate: '## Random Stimulation 분석 +promptTemplate: '## Random Stimulation Analysis - 이 프로젝트에서 예상치 못한 연결이나 비선형적 발상이 있는지 분석하세요. + Analyze if there are unexpected connections or non-linear ideas in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **예상치 못한 연결**: 논리적으로 연결되지 않는 요소들의 조합이 있는가? + 1. **Unexpected Connections**: Are there combinations of elements that are not logically connected? - 2. **비선형적 사고**: 점진적이지 않은 도약적 아이디어가 있는가? + 2. **Non-linear Thinking**: Are there leap ideas that are not incremental? - 3. **창의적 조합**: 일반적으로 연결되지 않는 것들을 연결했는가? + 3. **Creative Combination**: Did it connect things that are not generally connected? - 4. **serendipity**: 우연한 발견이나 영감의 흔적이 있는가? + 4. **Serendipity**: Are there traces of accidental discovery or inspiration? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 매우 예상치 못한 연결로 혁신적 아이디어 창출 + - 5 points: Innovative ideas created through very unexpected connections - - 4점: 비선형적 아이디어 연결이 명확함 + - 4 points: Non-linear idea connections are clear - - 3점: 일부 예상치 못한 요소 포함 + - 3 points: Contains some unexpected elements - - 2점: 대부분 논리적이고 예측 가능한 연결 + - 2 points: Mostly logical and predictable connections - - 1점: 모든 연결이 명백하고 선형적 + - 1 points: All connections are obvious and linear ' scoring: min: 1 max: 5 criteria: - 5: 예상치 못한 연결로 혁신적 아이디어 - 4: 비선형적 아이디어 연결 명확 - 3: 일부 예상치 못한 요소 - 2: 논리적이고 예측 가능한 연결 - 1: 모든 연결이 선형적 + 5: Innovative ideas via unexpected connections + 4: Clear non-linear connections + 3: Some unexpected elements + 2: Logical/predictable connections + 1: All linear connections outputSchema: score: number unexpectedConnections: string[] diff --git a/backend/app/techniques/definitions/palate/reversal-inversion.yaml b/backend/app/techniques/definitions/palate/reversal-inversion.yaml index ee6be2c..08d30a4 100644 --- a/backend/app/techniques/definitions/palate/reversal-inversion.yaml +++ b/backend/app/techniques/definitions/palate/reversal-inversion.yaml @@ -1,6 +1,5 @@ id: reversal-inversion name: Reversal Inversion -nameKo: 반전/역전 category: palate applicableHats: - green @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - A3 - B2 -description: '문제나 상황을 뒤집어서 바라보는 기법. +description: 'Technique to look at a problem or situation in reverse. - "반대로 하면 어떻게 될까?"를 질문하여 - - 새로운 관점과 해결책을 발견합니다. + Discovers new perspectives and solutions by asking "What if we do the opposite?". ' -promptTemplate: '## Reversal Inversion 분석 +promptTemplate: '## Reversal Inversion Analysis - 이 프로젝트가 문제를 역전시켜 바라본 흔적을 분석하세요. + Analyze traces of viewing the problem in reverse in this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **관점 역전**: 문제를 반대 방향에서 접근한 증거는? + 1. **Perspective Reversal**: Is there evidence of approaching the problem from the opposite direction? - 2. **역발상 적용**: "만약 반대로 한다면?"이라는 질문을 한 흔적은? + 2. **Applying Reverse Thinking**: Are there traces of asking "What if we do the opposite?"? - 3. **반직관적 해결**: 일반적인 상식과 다른 접근법이 있는가? + 3. **Counter-intuitive Solution**: Is there an approach different from general common sense? - 4. **새로운 인사이트**: 역전을 통해 발견한 새로운 통찰은? + 4. **New Insights**: What new insights were discovered through reversal? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 문제의 완전한 역전으로 획기적 돌파구 발견 + - 5 points: Breakthrough discovery through complete reversal of the problem - - 4점: 주요 가정의 역전 시도와 새로운 해결책 제시 + - 4 points: Attempted reversal of key assumptions and suggested new solutions - - 3점: 부분적 관점 전환 + - 3 points: Partial perspective shift - - 2점: 전통적 접근 유지 + - 2 points: Maintained traditional approach - - 1점: 역발상 흔적 없음 + - 1 points: No trace of reverse thinking ' scoring: min: 1 max: 5 criteria: - 5: 완전한 역전으로 획기적 돌파구 - 4: 주요 가정 역전 및 새 해결책 - 3: 부분적 관점 전환 - 2: 전통적 접근 유지 - 1: 역발상 없음 + 5: Breakthrough via complete reversal + 4: Reversed key assumptions, new solution + 3: Partial perspective shift + 2: Traditional approach + 1: No reverse thinking outputSchema: score: number reversalEvidence: string[] diff --git a/backend/app/techniques/definitions/palate/scamper.yaml b/backend/app/techniques/definitions/palate/scamper.yaml index 1fde580..a4d8c2f 100644 --- a/backend/app/techniques/definitions/palate/scamper.yaml +++ b/backend/app/techniques/definitions/palate/scamper.yaml @@ -1,6 +1,5 @@ id: scamper name: SCAMPER -nameKo: SCAMPER category: palate applicableHats: - green @@ -9,58 +8,56 @@ evaluationDimensions: - A3 - B1 - B3 -description: 'SCAMPER는 7가지 관점(Substitute, Combine, Adapt, Modify, Put to other uses, +description: 'SCAMPER is a creative thinking technique that transforms and innovates ideas from 7 perspectives (Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse). - Eliminate, Reverse)에서 아이디어를 변형하고 혁신하는 창의적 사고 기법. - - Bob Eberle가 Alex Osborn의 체크리스트를 발전시켜 개발. + Developed by Bob Eberle advancing Alex Osborn''s checklist. ' -promptTemplate: '## SCAMPER 분석 +promptTemplate: '## SCAMPER Analysis - 이 프로젝트가 SCAMPER 7가지 관점에서 얼마나 혁신적인지 분석하세요. + Analyze how innovative this project is from the 7 SCAMPER perspectives. - ### SCAMPER 7가지 관점: + ### SCAMPER 7 Perspectives: - 1. **S (Substitute)**: 기존 요소를 다른 것으로 대체했는가? + 1. **S (Substitute)**: Did it substitute existing elements with others? - 2. **C (Combine)**: 기존 기능/아이디어를 새롭게 결합했는가? + 2. **C (Combine)**: Did it combine existing functions/ideas anew? - 3. **A (Adapt)**: 다른 분야의 해결책을 적용했는가? + 3. **A (Adapt)**: Did it apply solutions from other fields? - 4. **M (Modify)**: 크기, 형태, 속성을 의미있게 변경했는가? + 4. **M (Modify)**: Did it meaningfully change size, shape, or attributes? - 5. **P (Put to other uses)**: 기존 것을 새로운 용도로 활용했는가? + 5. **P (Put to other uses)**: Did it use existing things for new purposes? - 6. **E (Eliminate)**: 불필요한 요소를 제거하여 단순화했는가? + 6. **E (Eliminate)**: Did it eliminate unnecessary elements to simplify? - 7. **R (Reverse/Rearrange)**: 순서나 관점을 뒤집어 새로운 가치를 창출했는가? + 7. **R (Reverse/Rearrange)**: Did it reverse order or perspective to create new value? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5개 이상 SCAMPER 요소가 명확히 적용됨 + - 5 points: 5+ SCAMPER elements clearly applied - - 4점: 3-4개 SCAMPER 요소가 적용됨 + - 4 points: 3-4 SCAMPER elements applied - - 3점: 2개 SCAMPER 요소가 적용됨 + - 3 points: 2 SCAMPER elements applied - - 2점: 1개 SCAMPER 요소만 부분적으로 적용 + - 2 points: 1 SCAMPER element partially applied - - 1점: SCAMPER 요소 적용 없음 (기존 방식 그대로) + - 1 points: No SCAMPER elements applied (Existing method as is) ' scoring: min: 1 max: 5 criteria: - 5: 5개+ SCAMPER 요소 명확히 적용 - 4: 3-4개 SCAMPER 요소 적용 - 3: 2개 SCAMPER 요소 적용 - 2: 1개 요소 부분 적용 - 1: SCAMPER 적용 없음 + 5: 5+ SCAMPER elements applied + 4: 3-4 SCAMPER elements applied + 3: 2 SCAMPER elements applied + 2: 1 element partial applied + 1: No SCAMPER application outputSchema: score: number substituteEvidence: string @@ -77,4 +74,4 @@ metadata: requiresWebSearch: false requiresRAG: false source: Bob Eberle / Alex Osborn - requiredSources: either +requiredSources: both diff --git a/backend/app/techniques/definitions/palate/triz.yaml b/backend/app/techniques/definitions/palate/triz.yaml index 0acfadc..0b72d0b 100644 --- a/backend/app/techniques/definitions/palate/triz.yaml +++ b/backend/app/techniques/definitions/palate/triz.yaml @@ -1,6 +1,5 @@ id: triz name: TRIZ -nameKo: 트리즈 category: palate applicableHats: - green @@ -9,54 +8,52 @@ evaluationDimensions: - A3 - B1 - B2 -description: 'Genrich Altshuller가 200,000+ 특허 분석을 통해 개발한 체계적 발명 방법론. +description: 'Systematic invention methodology developed by Genrich Altshuller through analysis of 200,000+ patents. - 모순 해결, 40가지 발명 원리, 기술 진화 법칙을 활용하여 - - 혁신적인 문제 해결을 이끌어내는 공학적 창의성 기법. + Engineering creativity technique that derives innovative problem solutions utilizing contradiction resolution, 40 inventive principles, and laws of technical evolution. ' -promptTemplate: '## TRIZ 분석 +promptTemplate: '## TRIZ Analysis - 이 프로젝트가 TRIZ 원리를 얼마나 활용했는지 분석하세요. + Analyze how much this project utilized TRIZ principles. - ### TRIZ 핵심 개념: + ### TRIZ Core Concepts: - 1. **모순 식별**: 기술적/물리적 모순을 인식했는가? + 1. **Identify Contradiction**: Did it recognize technical/physical contradictions? - 2. **40가지 발명 원리**: 분할, 추출, 국소적 품질 등 원리 적용? + 2. **40 Inventive Principles**: Applied principles like segmentation, extraction, local quality? - 3. **이상적 최종 결과**: 이상적인 솔루션을 정의했는가? + 3. **Ideal Final Result**: Did it define the ideal solution? - 4. **자원 활용**: 기존 자원을 창의적으로 활용했는가? + 4. **Resource Utilization**: Did it creatively use existing resources? - 5. **기술 진화**: 기술 발전 패턴을 고려했는가? + 5. **Technical Evolution**: Did it consider technology evolution patterns? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 모순 해결, 다수 발명 원리 적용, 이상적 결과 달성 + - 5 points: Resolved contradictions, applied multiple principles, achieved ideal result - - 4점: 명확한 모순 인식, 2-3개 발명 원리 적용 + - 4 points: Clear contradiction recognition, applied 2-3 principles - - 3점: 일부 모순 인식, 1개 발명 원리 적용 + - 3 points: Recognized some contradictions, applied 1 principle - - 2점: 암묵적 모순 해결 시도 + - 2 points: Implicit contradiction resolution attempt - - 1점: TRIZ 개념 미적용 + - 1 points: TRIZ concepts not applied ' scoring: min: 1 max: 5 criteria: - 5: 모순 해결, 다수 원리 적용 - 4: 명확한 모순, 2-3개 원리 - 3: 일부 모순, 1개 원리 - 2: 암묵적 모순 해결 - 1: TRIZ 미적용 + 5: Resolved contradictions, multiple principles + 4: Clear contradiction, 2-3 principles + 3: Some contradiction, 1 principle + 2: Implicit resolution + 1: TRIZ not applied outputSchema: score: number contradictionsIdentified: string[] @@ -70,5 +67,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Genrich Altshuller (1946-1956) - academicReference: 200,000+ 특허 분석 기반, Samsung/GE/Intel 도입 + academicReference: Based on 200,000+ patent analyses, adopted by Samsung/GE/Intel requiredSources: both diff --git a/backend/app/techniques/definitions/terroir/drunk-history-retelling.yaml b/backend/app/techniques/definitions/terroir/drunk-history-retelling.yaml index ba8c432..7d99414 100644 --- a/backend/app/techniques/definitions/terroir/drunk-history-retelling.yaml +++ b/backend/app/techniques/definitions/terroir/drunk-history-retelling.yaml @@ -1,6 +1,5 @@ id: drunk-history-retelling name: Drunk History Retelling -nameKo: 취중 역사 리텔링 category: terroir applicableHats: - green @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - D2 - D3 -description: '복잡한 이야기를 친구에게 술자리에서 +description: 'Technique to explain complex stories simply and funnily as if explaining to a friend over drinks. - 설명하듯 단순하고 재미있게 전달하는 기법. - - 핵심만 남기고 재미있게 풀어냅니다. + Leaves only the core and unravels it in an interesting way. ' -promptTemplate: '## Drunk History Retelling 분석 +promptTemplate: '## Drunk History Retelling Analysis - 프로젝트를 단순하고 재미있게 설명할 수 있는지 분석하세요. + Analyze if the project can be explained simply and funnily. - ### 분석 관점: + ### Analysis Perspectives: - 1. **단순화**: 복잡한 것을 쉽게 설명할 수 있는가? + 1. **Simplification**: Can complex things be explained easily? - 2. **핵심 추출**: 가장 중요한 포인트가 명확한가? + 2. **Core Extraction**: Is the most important point clear? - 3. **재미 요소**: 이야기에 재미가 있는가? + 3. **Fun Factor**: Is there fun in the story? - 4. **기억성**: 한 줄로 기억할 수 있는가? + 4. **Memorability**: Can it be remembered in one line? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 한 줄 요약 가능, 재미있고 기억에 남음 + - 5 points: One-line summary possible, funny and memorable - - 4점: 쉬운 설명과 명확한 핵심 + - 4 points: Easy explanation and clear core - - 3점: 어느 정도 단순화 + - 3 points: Some simplification - - 2점: 여전히 복잡 + - 2 points: Still complex - - 1점: 단순화 불가 + - 1 points: Cannot simplify ' scoring: min: 1 max: 5 criteria: - 5: 한 줄 요약, 재미, 기억성 - 4: 쉬운 설명, 명확한 핵심 - 3: 어느 정도 단순화 - 2: 여전히 복잡 - 1: 단순화 불가 + 5: One-line summary, funny, memorable + 4: Easy explanation, clear core + 3: Some simplification + 2: Still complex + 1: Cannot simplify outputSchema: score: number oneLiner: string diff --git a/backend/app/techniques/definitions/terroir/emotion-orchestra.yaml b/backend/app/techniques/definitions/terroir/emotion-orchestra.yaml index 36f8991..bc38ce8 100644 --- a/backend/app/techniques/definitions/terroir/emotion-orchestra.yaml +++ b/backend/app/techniques/definitions/terroir/emotion-orchestra.yaml @@ -1,6 +1,5 @@ id: emotion-orchestra name: Emotion Orchestra -nameKo: 감정 오케스트라 category: terroir applicableHats: - red @@ -8,52 +7,50 @@ evaluationDimensions: - C2 - D2 - D3 -description: '프레젠테이션의 감정 흐름을 오케스트라처럼 +description: 'Technique to orchestrate the emotional flow of a presentation like an orchestra. - 조율하는 기법. 긴장, 이완, 클라이맥스를 - - 의도적으로 설계합니다. + Intentionally designs tension, relaxation, and climax. ' -promptTemplate: '## Emotion Orchestra 분석 +promptTemplate: '## Emotion Orchestra Analysis - 프로젝트 발표가 감정 흐름을 효과적으로 설계했는지 분석하세요. + Analyze if the project presentation effectively designed emotional flow. - ### 분석 관점: + ### Analysis Perspectives: - 1. **감정 곡선**: 발표의 감정 흐름이 설계되었는가? + 1. **Emotional Curve**: Is the emotional flow of the presentation designed? - 2. **긴장과 이완**: 긴장-이완의 리듬이 있는가? + 2. **Tension and Relaxation**: Is there a rhythm of tension-relaxation? - 3. **클라이맥스**: 감정의 정점이 있는가? + 3. **Climax**: Is there an emotional peak? - 4. **여운**: 끝맺음의 감정적 여운이 있는가? + 4. **Aftertaste**: Is there an emotional lingering effect at the end? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완벽한 감정 곡선, 강렬한 클라이맥스, 깊은 여운 + - 5 points: Perfect emotional curve, intense climax, deep aftertaste - - 4점: 효과적인 감정 흐름 설계 + - 4 points: Effective emotional flow design - - 3점: 일부 감정 변화 + - 3 points: Some emotional changes - - 2점: 평탄한 감정 + - 2 points: Flat emotion - - 1점: 감정 고려 없음 + - 1 points: No consideration of emotion ' scoring: min: 1 max: 5 criteria: - 5: 완벽한 곡선, 클라이맥스, 여운 - 4: 효과적 감정 흐름 - 3: 일부 감정 변화 - 2: 평탄한 감정 - 1: 감정 무고려 + 5: Perfect curve, climax, aftertaste + 4: Effective emotional flow + 3: Some emotional changes + 2: Flat emotion + 1: No emotion consideration outputSchema: score: number emotionalCurve: string diff --git a/backend/app/techniques/definitions/terroir/metaphor-mapping.yaml b/backend/app/techniques/definitions/terroir/metaphor-mapping.yaml index b17864c..edf4074 100644 --- a/backend/app/techniques/definitions/terroir/metaphor-mapping.yaml +++ b/backend/app/techniques/definitions/terroir/metaphor-mapping.yaml @@ -1,6 +1,5 @@ id: metaphor-mapping name: Metaphor Mapping -nameKo: 은유 매핑 category: terroir applicableHats: - green @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - D2 - D3 -description: '복잡한 개념을 친숙한 은유로 설명하는 기법. +description: 'Technique to explain complex concepts with familiar metaphors. - 추상적인 아이디어를 구체적이고 - - 이해하기 쉬운 비유로 표현합니다. + Expresses abstract ideas with concrete and easy-to-understand analogies. ' -promptTemplate: '## Metaphor Mapping 분석 +promptTemplate: '## Metaphor Mapping Analysis - 프로젝트가 효과적인 은유를 사용했는지 분석하세요. + Analyze if the project used effective metaphors. - ### 분석 관점: + ### Analysis Perspectives: - 1. **은유 사용**: 복잡한 개념을 비유로 설명했는가? + 1. **Metaphor Usage**: Did it explain complex concepts with analogies? - 2. **적절성**: 은유가 개념을 잘 전달하는가? + 2. **Appropriateness**: Does the metaphor convey the concept well? - 3. **일관성**: 은유가 전체적으로 일관성 있는가? + 3. **Consistency**: Is the metaphor consistent overall? - 4. **기억성**: 은유가 기억에 남는가? + 4. **Memorability**: Is the metaphor memorable? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 강력한 핵심 은유, 일관성, 높은 기억성 + - 5 points: Powerful core metaphor, consistency, high memorability - - 4점: 효과적인 은유 사용 + - 4 points: Effective use of metaphor - - 3점: 일부 비유 사용 + - 3 points: Some analogies used - - 2점: 산발적 비유 + - 2 points: Sporadic analogies - - 1점: 은유 없음 + - 1 points: No metaphors ' scoring: min: 1 max: 5 criteria: - 5: 강력한 은유, 일관성, 기억성 - 4: 효과적 은유 사용 - 3: 일부 비유 - 2: 산발적 비유 - 1: 은유 없음 + 5: Powerful metaphor, consistency, memorable + 4: Effective metaphor use + 3: Some analogies + 2: Sporadic analogies + 1: No metaphors outputSchema: score: number coreMetaphors: string[] diff --git a/backend/app/techniques/definitions/terroir/mythic-frameworks.yaml b/backend/app/techniques/definitions/terroir/mythic-frameworks.yaml index 99b8c8f..742f100 100644 --- a/backend/app/techniques/definitions/terroir/mythic-frameworks.yaml +++ b/backend/app/techniques/definitions/terroir/mythic-frameworks.yaml @@ -1,6 +1,5 @@ id: mythic-frameworks name: Mythic Frameworks -nameKo: 신화적 프레임워크 category: terroir applicableHats: - red @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - D2 - D3 -description: 'Joseph Campbell의 영웅의 여정 등 +description: 'Technique utilizing universal narrative structures like Joseph Campbell''s Hero''s Journey. - 보편적 서사 구조를 활용하는 기법. - - 프로젝트 스토리에 신화적 깊이를 부여합니다. + Gives mythic depth to the project story. ' -promptTemplate: '## Mythic Frameworks 분석 +promptTemplate: '## Mythic Frameworks Analysis - 프로젝트가 신화적 서사 구조를 활용했는지 분석하세요. + Analyze if the project utilized mythic narrative structures. - ### 분석 관점: + ### Analysis Perspectives: - 1. **영웅의 여정**: 도전-시련-성장의 서사가 있는가? + 1. **Hero''s Journey**: Is there a narrative of Challenge-Ordeal-Growth? - 2. **보편적 테마**: 인류 보편의 주제와 연결되는가? + 2. **Universal Theme**: Does it connect with universal human themes? - 3. **감정적 공명**: 깊은 감정적 울림이 있는가? + 3. **Emotional Resonance**: Is there deep emotional resonance? - 4. **변환의 서사**: 변화와 성장의 이야기가 있는가? + 4. **Transformation Arc**: Is there a story of change and growth? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 완전한 영웅의 여정, 깊은 감정적 공명 + - 5 points: Complete Hero''s Journey, deep emotional resonance - - 4점: 명확한 서사 구조와 테마 + - 4 points: Clear narrative structure and theme - - 3점: 기본적인 스토리 구조 + - 3 points: Basic story structure - - 2점: 약한 서사 + - 2 points: Weak narrative - - 1점: 서사 구조 없음 + - 1 points: No narrative structure ' scoring: min: 1 max: 5 criteria: - 5: 완전한 영웅 여정, 감정 공명 - 4: 명확한 서사와 테마 - 3: 기본 스토리 구조 - 2: 약한 서사 - 1: 서사 없음 + 5: Complete Hero's Journey, emotional resonance + 4: Clear narrative and theme + 3: Basic story structure + 2: Weak narrative + 1: No narrative structure outputSchema: score: number narrativeStructure: string diff --git a/backend/app/techniques/definitions/terroir/time-travel-talk-show.yaml b/backend/app/techniques/definitions/terroir/time-travel-talk-show.yaml index 9c90f55..091778c 100644 --- a/backend/app/techniques/definitions/terroir/time-travel-talk-show.yaml +++ b/backend/app/techniques/definitions/terroir/time-travel-talk-show.yaml @@ -1,6 +1,5 @@ id: time-travel-talk-show name: Time Travel Talk Show -nameKo: 시간여행 토크쇼 category: terroir applicableHats: - green @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - D2 - D3 -description: '미래의 시점에서 현재 프로젝트를 소개하는 +description: 'Technique to imagine a fictional talk show introducing the current project from a future perspective. - 가상의 토크쇼를 상상하는 기법. - - 성공 후의 관점에서 스토리를 구성합니다. + Constructs a story from the perspective of success. ' -promptTemplate: '## Time Travel Talk Show 분석 +promptTemplate: '## Time Travel Talk Show Analysis - 프로젝트가 미래 성공 관점에서 스토리를 구성했는지 분석하세요. + Analyze if the project constructed a story from a future success perspective. - ### 분석 관점: + ### Analysis Perspectives: - 1. **미래 시점**: 성공한 미래 시점을 설정했는가? + 1. **Future Viewpoint**: Is a successful future viewpoint established? - 2. **성공 스토리**: 어떻게 성공했는지 서술했는가? + 2. **Success Story**: Is it described how it succeeded? - 3. **임팩트**: 만들어낸 변화를 설명했는가? + 3. **Impact**: Is the created change explained? - 4. **여정 회고**: 여정의 핵심 순간들을 담았는가? + 4. **Journey Retrospective**: Does it contain key moments of the journey? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 생생한 미래 스토리, 임팩트 명확, 설득력 있는 여정 + - 5 points: Vivid future story, clear impact, persuasive journey - - 4점: 명확한 성공 비전과 스토리 + - 4 points: Clear success vision and story - - 3점: 일부 미래 전망 + - 3 points: Some future outlook - - 2점: 막연한 미래 언급 + - 2 points: Vague future reference - - 1점: 미래 시점 없음 + - 1 points: No future viewpoint ' scoring: min: 1 max: 5 criteria: - 5: 생생한 미래, 임팩트, 설득력 - 4: 명확한 성공 비전 - 3: 일부 미래 전망 - 2: 막연한 미래 - 1: 미래 시점 없음 + 5: Vivid future, clear impact, persuasive + 4: Clear success vision + 3: Some future outlook + 2: Vague future + 1: No future viewpoint outputSchema: score: number futureTimeline: string diff --git a/backend/app/techniques/definitions/vintage/future-self-interview.yaml b/backend/app/techniques/definitions/vintage/future-self-interview.yaml index 9cfddc5..96db69e 100644 --- a/backend/app/techniques/definitions/vintage/future-self-interview.yaml +++ b/backend/app/techniques/definitions/vintage/future-self-interview.yaml @@ -1,6 +1,5 @@ id: future-self-interview name: Future Self Interview -nameKo: 미래 자아 인터뷰 category: vintage applicableHats: - yellow @@ -8,52 +7,50 @@ applicableHats: evaluationDimensions: - D1 - D3 -description: '성공한 미래의 자신을 상상하고 +description: 'Technique to imagine a successful future self and reflect on the present from that perspective. - 그 관점에서 현재를 돌아보는 기법. - - 비전을 명확히 하고 역방향으로 계획을 세웁니다. + Clarifies vision and plans backwards. ' -promptTemplate: '## Future Self Interview 분석 +promptTemplate: '## Future Self Interview Analysis - 프로젝트가 미래 성공 관점에서 현재를 설계했는지 분석하세요. + Analyze if the project designed the present from a future success perspective. - ### 분석 관점: + ### Analysis Perspectives: - 1. **성공 비전**: 성공한 미래를 구체적으로 그렸는가? + 1. **Success Vision**: Is the successful future visualized concretely? - 2. **역방향 계획**: 미래에서 현재로 역산했는가? + 2. **Backward Planning**: Is there a backward calculation from future to present? - 3. **마일스톤**: 중간 목표를 설정했는가? + 3. **Milestones**: Are intermediate goals set? - 4. **현재 행동**: 지금 해야 할 일을 명확히 했는가? + 4. **Current Actions**: Are the things to do now clear? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 생생한 성공 비전, 역방향 계획, 명확한 마일스톤 + - 5 points: Vivid success vision, backward planning, clear milestones - - 4점: 명확한 미래 비전과 계획 + - 4 points: Clear future vision and plan - - 3점: 일부 미래 목표 설정 + - 3 points: Some future goals set - - 2점: 막연한 미래 언급 + - 2 points: Vague future reference - - 1점: 미래 비전 없음 + - 1 points: No future vision ' scoring: min: 1 max: 5 criteria: - 5: 생생한 비전, 역방향 계획, 마일스톤 - 4: 명확한 비전과 계획 - 3: 일부 미래 목표 - 2: 막연한 미래 - 1: 미래 비전 없음 + 5: Vivid vision, backward planning, milestones + 4: Clear vision and plan + 3: Some future goals + 2: Vague future + 1: No future vision outputSchema: score: number successVision: string diff --git a/backend/app/techniques/definitions/vintage/okr.yaml b/backend/app/techniques/definitions/vintage/okr.yaml index b42f8e3..3708bad 100644 --- a/backend/app/techniques/definitions/vintage/okr.yaml +++ b/backend/app/techniques/definitions/vintage/okr.yaml @@ -1,6 +1,5 @@ id: okr name: OKR -nameKo: 목표 및 핵심 결과 category: vintage applicableHats: - yellow @@ -10,54 +9,52 @@ evaluationDimensions: - A1 - C1 - C4 -description: 'Andy Grove(Intel, 1970s)가 개발하고 John Doerr가 Google에 도입한 목표 관리 체계. +description: 'Goal management system developed by Andy Grove (Intel, 1970s) and introduced to Google by John Doerr. - Objectives(목표)와 Key Results(핵심 결과)를 연결하여 - - 조직의 방향성과 측정 가능한 성과 지표를 명확히 정의. + Clearly defines organizational direction and measurable performance indicators by connecting Objectives and Key Results. ' -promptTemplate: '## OKR 분석 +promptTemplate: '## OKR Analysis - 이 프로젝트가 OKR 프레임워크로 목표와 성과를 정의했는지 평가하세요. + Evaluate if this project defined goals and performance using the OKR framework. - ### OKR 핵심 원칙: + ### OKR Core Principles: - 1. **Objective (목표)**: 영감을 주는 질적 목표인가? + 1. **Objective**: Is it an inspiring qualitative goal? - 2. **Key Results (핵심 결과)**: 측정 가능한 정량적 지표인가? + 2. **Key Results**: Are they measurable quantitative indicators? - 3. **도전적 목표**: 70% 달성 가능한 stretch goal인가? + 3. **Challenging Goal**: Is it a stretch goal achievable at 70%? - 4. **정렬(Alignment)**: 팀/개인 OKR이 상위 목표와 연결되는가? + 4. **Alignment**: Do team/individual OKRs connect to higher goals? - 5. **투명성**: OKR이 공개되고 추적 가능한가? + 5. **Transparency**: Are OKRs public and trackable? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 명확한 OKR 체계, 측정 가능, 정렬 완료 + - 5 points: Clear OKR system, measurable, fully aligned - - 4점: 목표+핵심 결과 정의, 대부분 측정 가능 + - 4 points: O+KR defined, mostly measurable - - 3점: 목표는 명확하나 KR이 모호 + - 3 points: Clear objective but vague KRs - - 2점: 일반적인 목표만 존재 + - 2 points: Only general goals exist - - 1점: 목표 정의 없음 + - 1 points: No goal definition ' scoring: min: 1 max: 5 criteria: - 5: 완전한 OKR, 측정 가능, 정렬 - 4: O+KR 정의, 대부분 측정 가능 - 3: 목표 명확, KR 모호 - 2: 일반적 목표만 - 1: 목표 정의 없음 + 5: Complete OKR, measurable, aligned + 4: O+KR defined, mostly measurable + 3: Objective clear, KR vague + 2: General goals only + 1: No goal definition outputSchema: score: number objectives: string[] @@ -72,5 +69,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Andy Grove, Intel (1970s) / John Doerr - academicReference: Google 성장 기여, 'Measure What Matters' (2018) + academicReference: Contributed to Google's growth, 'Measure What Matters' (2018) requiredSources: either diff --git a/backend/app/techniques/definitions/vintage/opportunity-spotting.yaml b/backend/app/techniques/definitions/vintage/opportunity-spotting.yaml index fc3635a..c2ea320 100644 --- a/backend/app/techniques/definitions/vintage/opportunity-spotting.yaml +++ b/backend/app/techniques/definitions/vintage/opportunity-spotting.yaml @@ -1,6 +1,5 @@ id: opportunity-spotting name: Opportunity Spotting -nameKo: 기회 발견 category: vintage applicableHats: - yellow @@ -8,52 +7,52 @@ evaluationDimensions: - A4 - B1 - B3 -description: '프로젝트가 포착한 시장 기회와 성장 잠재력을 분석하는 기법. +description: 'Technique to analyze market opportunities and growth potential captured by the project. - 현재 상태뿐 아니라 미래 확장 가능성과 새로운 기회를 식별. + Identifies future expansion possibilities and new opportunities as well as current status. ' -promptTemplate: '## Opportunity Spotting (기회 발견 분석) +promptTemplate: '## Opportunity Spotting Analysis - 이 프로젝트가 어떤 기회를 포착했고, 어떤 잠재력이 있는지 분석하세요. + Analyze what opportunities this project has captured and what potential it has. - ### 분석 관점: + ### Analysis Perspectives: - 1. **시장 기회**: 어떤 시장 기회를 포착했는가? + 1. **Market Opportunity**: What market opportunity was captured? - 2. **타이밍**: 지금이 이 솔루션을 위한 적절한 시기인가? + 2. **Timing**: Is now the right time for this solution? - 3. **확장 가능성**: 초기 시장을 넘어 확장할 수 있는가? + 3. **Scalability**: Can it expand beyond the initial market? - 4. **네트워크 효과**: 사용자가 늘수록 가치가 증가하는가? + 4. **Network Effects**: Does value increase as users increase? - 5. **진입 장벽**: 경쟁자 대비 방어 가능한 위치인가? + 5. **Barriers to Entry**: Is the position defensible against competitors? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 명확한 시장 기회 + 높은 확장성 + 강한 방어력 + - 5 points: Clear market opportunity + High scalability + Strong defense - - 4점: 좋은 시장 기회 + 확장 가능성 있음 + - 4 points: Good market opportunity + Scalability exists - - 3점: 시장 기회는 있으나 제한적 + - 3 points: Market opportunity exists but limited - - 2점: 기회가 불명확하거나 시장이 작음 + - 2 points: Opportunity unclear or market is small - - 1점: 시장 기회 분석 없음 + - 1 points: No market opportunity analysis ' scoring: min: 1 max: 5 criteria: - 5: 명확한 기회 + 높은 확장성 + 방어력 - 4: 좋은 기회 + 확장 가능성 - 3: 기회 있으나 제한적 - 2: 불명확한 기회 - 1: 기회 분석 없음 + 5: Clear opportunity + High scalability + Defense + 4: Good opportunity + Scalability + 3: Opportunity exists but limited + 2: Unclear opportunity + 1: No opportunity analysis outputSchema: score: number marketOpportunity: string diff --git a/backend/app/techniques/definitions/vintage/permission-giving.yaml b/backend/app/techniques/definitions/vintage/permission-giving.yaml index c4a4949..d6e9109 100644 --- a/backend/app/techniques/definitions/vintage/permission-giving.yaml +++ b/backend/app/techniques/definitions/vintage/permission-giving.yaml @@ -1,6 +1,5 @@ id: permission-giving name: Permission Giving -nameKo: 허락 주기 category: vintage applicableHats: - yellow @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - C2 - D3 -description: '스스로에게 "~해도 된다"라고 허락을 주어 +description: 'Technique to release self-limitation by giving permission to oneself saying "It''s okay to...". - 자기 제한을 해제하는 기법. - - 내면의 비판자를 잠재우고 자유롭게 상상합니다. + Silences the inner critic and imagines freely. ' -promptTemplate: '## Permission Giving 분석 +promptTemplate: '## Permission Giving Analysis - 프로젝트가 자기 제한을 극복하고 과감한 시도를 했는지 분석하세요. + Analyze if the project overcame self-limitations and made bold attempts. - ### 분석 관점: + ### Analysis Perspectives: - 1. **자기 제한 인식**: 스스로의 제한을 인식했는가? + 1. **Self-limitation Awareness**: Were self-limitations recognized? - 2. **허락 부여**: "~해도 된다"고 스스로 허락했는가? + 2. **Giving Permission**: Did they give permission saying "It''s okay to..."? - 3. **과감한 시도**: 평소 하지 않던 시도를 했는가? + 3. **Bold Attempt**: Did they try things they wouldn''t normally do? - 4. **제약 해제**: 불필요한 제약을 해제했는가? + 4. **Constraint Release**: Were unnecessary constraints released? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 자기 제한 극복, 과감한 시도, 새로운 영역 개척 + - 5 points: Overcame self-limitation, bold attempt, pioneered new area - - 4점: 의식적으로 제한 해제 + - 4 points: Consciously released limitations - - 3점: 일부 새로운 시도 + - 3 points: Some new attempts - - 2점: 안전지대 내에서만 활동 + - 2 points: Activity within comfort zone - - 1점: 자기 제한 인식 없음 + - 1 points: No awareness of self-limitation ' scoring: min: 1 max: 5 criteria: - 5: 제한 극복, 과감한 시도 - 4: 의식적 제한 해제 - 3: 일부 새로운 시도 - 2: 안전지대 내 활동 - 1: 제한 인식 없음 + 5: Overcame limitation, bold attempt + 4: Conscious release + 3: Some new attempts + 2: Comfort zone activity + 1: No limitation awareness outputSchema: score: number selfLimitations: string[] diff --git a/backend/app/techniques/definitions/vintage/plus-points.yaml b/backend/app/techniques/definitions/vintage/plus-points.yaml index 6d3a8d3..c8289ca 100644 --- a/backend/app/techniques/definitions/vintage/plus-points.yaml +++ b/backend/app/techniques/definitions/vintage/plus-points.yaml @@ -1,6 +1,5 @@ id: plus-points name: Plus Points Analysis -nameKo: 플러스 포인트 category: vintage applicableHats: - yellow @@ -8,54 +7,54 @@ evaluationDimensions: - A3 - A4 - C1 -description: '프로젝트의 긍정적인 측면과 강점을 체계적으로 식별하는 기법. +description: 'Technique to systematically identify positive aspects and strengths of the project. - 비판 이전에 가치 있는 부분을 먼저 인정하고 발굴. + Acknowledges and excavates valuable parts before criticism. ' -promptTemplate: '## Plus Points Analysis (플러스 포인트 분석) +promptTemplate: '## Plus Points Analysis - 이 프로젝트의 긍정적인 측면과 강점을 찾으세요. + Find the positive aspects and strengths of this project. - 비판적 시각은 배제하고, 오직 좋은 점만 집중적으로 분석하세요. + Exclude critical views and focus exclusively on good points. - ### 분석 관점: + ### Analysis Perspectives: - 1. **핵심 강점**: 이 프로젝트의 가장 큰 강점은? + 1. **Core Strength**: What is the greatest strength of this project? - 2. **독창성**: 다른 프로젝트와 차별화되는 긍정적 요소는? + 2. **Originality**: What positive elements differentiate it from other projects? - 3. **실행력**: 팀이 잘 해낸 부분은? + 3. **Execution**: What did the team do well? - 4. **가치 제공**: 사용자에게 제공하는 명확한 가치는? + 4. **Value Provision**: What clear value does it provide to users? - 5. **기술적 장점**: 기술적으로 잘 구현된 부분은? + 5. **Technical Merit**: What parts are technically well implemented? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 5개 이상의 명확한 강점, 차별화된 가치 + - 5 points: 5+ clear strengths, differentiated value - - 4점: 3-4개의 강점, 좋은 실행력 + - 4 points: 3-4 strengths, good execution - - 3점: 2개의 강점, 평균적 수준 + - 3 points: 2 strengths, average level - - 2점: 1개의 강점, 미흡한 부분이 많음 + - 2 points: 1 strength, many insufficient parts - - 1점: 명확한 강점을 찾기 어려움 + - 1 points: Difficult to find clear strengths ' scoring: min: 1 max: 5 criteria: - 5: 5개+ 명확한 강점, 차별화된 가치 - 4: 3-4개 강점, 좋은 실행력 - 3: 2개 강점, 평균 수준 - 2: 1개 강점 - 1: 명확한 강점 없음 + 5: 5+ clear strengths, differentiated value + 4: 3-4 strengths, good execution + 3: 2 strengths, average level + 2: 1 strength + 1: No clear strengths outputSchema: score: number coreStrengths: string[] diff --git a/backend/app/techniques/definitions/vintage/scenario-planning.yaml b/backend/app/techniques/definitions/vintage/scenario-planning.yaml index f111614..16a066f 100644 --- a/backend/app/techniques/definitions/vintage/scenario-planning.yaml +++ b/backend/app/techniques/definitions/vintage/scenario-planning.yaml @@ -1,6 +1,5 @@ id: scenario-planning name: Scenario Planning -nameKo: 시나리오 플래닝 category: vintage applicableHats: - yellow @@ -10,56 +9,54 @@ evaluationDimensions: - A4 - B3 - B4 -description: 'Herman Kahn(RAND Corporation)과 Pierre Wack(Shell)이 발전시킨 전략 기획 기법. +description: 'Strategic planning technique developed by Herman Kahn (RAND Corporation) and Pierre Wack (Shell). - 불확실한 미래에 대해 여러 시나리오를 구성하고, + Methodology to construct multiple scenarios for an uncertain future and prepare strategic responses for each. - 각 시나리오에 대한 전략적 대응을 준비하는 방법론. - - Shell은 1973년 석유위기를 이 기법으로 예측하고 대비. + Shell predicted and prepared for the 1973 oil crisis using this technique. ' -promptTemplate: '## Scenario Planning 분석 +promptTemplate: '## Scenario Planning Analysis - 이 프로젝트가 시나리오 플래닝으로 미래를 대비했는지 평가하세요. + Evaluate if this project prepared for the future using Scenario Planning. - ### Scenario Planning 핵심 요소: + ### Scenario Planning Core Elements: - 1. **핵심 불확실성**: 미래를 좌우하는 주요 변수 식별? + 1. **Key Uncertainties**: Identified key variables determining the future? - 2. **시나리오 구성**: 최소 2-4개 대안 미래 시나리오? + 2. **Scenario Construction**: At least 2-4 alternative future scenarios? - 3. **각 시나리오의 논리**: 내적 일관성과 타당성? + 3. **Logic of Each Scenario**: Internal consistency and validity? - 4. **조기 경고 지표**: 어떤 시나리오로 전개되는지 알려주는 신호? + 4. **Early Warning Indicators**: Signals indicating which scenario is unfolding? - 5. **전략적 대응**: 각 시나리오별 대응 전략? + 5. **Strategic Response**: Response strategies for each scenario? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다중 시나리오, 조기 경고, 전략별 대응 + - 5 points: Multiple scenarios, early warnings, response per strategy - - 4점: 3-4개 시나리오, 대응 전략 수립 + - 4 points: 3-4 scenarios, strategy established - - 3점: 2개 시나리오(최선/최악) + - 3 points: 2 scenarios (Best/Worst) - - 2점: 단일 시나리오만 고려 + - 2 points: Only single scenario considered - - 1점: 미래 대비 없음 + - 1 points: No preparation for future ' scoring: min: 1 max: 5 criteria: - 5: 다중 시나리오, 조기 경고, 대응 - 4: 3-4개 시나리오, 전략 수립 - 3: 2개 시나리오 - 2: 단일 시나리오 - 1: 미래 대비 없음 + 5: Multiple scenarios, early warning, response + 4: 3-4 scenarios, strategy established + 3: 2 scenarios + 2: Single scenario + 1: No preparation outputSchema: score: number keyUncertainties: string[] @@ -74,5 +71,5 @@ metadata: requiresWebSearch: false requiresRAG: false source: Herman Kahn (RAND), Pierre Wack (Shell) - academicReference: Shell 1973 석유위기 예측 성공, 전략경영 표준 도구 + academicReference: Successfully predicted Shell 1973 oil crisis, standard tool for strategic management requiredSources: either diff --git a/backend/app/techniques/definitions/vintage/strength-analysis.yaml b/backend/app/techniques/definitions/vintage/strength-analysis.yaml index 0075fe4..c249bf3 100644 --- a/backend/app/techniques/definitions/vintage/strength-analysis.yaml +++ b/backend/app/techniques/definitions/vintage/strength-analysis.yaml @@ -1,6 +1,5 @@ id: strength-analysis name: Strength Analysis -nameKo: 강점 분석 category: vintage applicableHats: - yellow @@ -8,52 +7,52 @@ evaluationDimensions: - A3 - B1 - C1 -description: '프로젝트의 경쟁 우위와 핵심 강점을 체계적으로 식별하고 +description: 'Technique to systematically identify and analyze the project''s competitive advantages and core strengths. - 분석하는 기법. SWOT의 Strengths에 집중한 심층 분석. + In-depth analysis focusing on Strengths of SWOT. ' -promptTemplate: '## Strength Analysis (강점 분석) +promptTemplate: '## Strength Analysis - 이 프로젝트의 핵심 강점과 경쟁 우위를 심층 분석하세요. + Deeply analyze the core strengths and competitive advantages of this project. - ### 분석 관점: + ### Analysis Perspectives: - 1. **핵심 역량**: 팀이 가진 독특한 역량은? + 1. **Core Competency**: What unique capabilities does the team have? - 2. **기술적 강점**: 기술적으로 뛰어난 부분은? + 2. **Technical Strength**: What are the technically superior parts? - 3. **차별화 요소**: 경쟁자와 구별되는 점은? + 3. **Differentiator**: What distinguishes it from competitors? - 4. **자원 강점**: 팀이 보유한 특별한 자원은? + 4. **Resource Strength**: What special resources does the team possess? - 5. **실행 강점**: 실행력에서 뛰어난 부분은? + 5. **Execution Strength**: What parts excel in execution? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 명확하고 지속 가능한 경쟁 우위 3개 이상 + - 5 points: 3+ clear and sustainable competitive advantages - - 4점: 2개의 명확한 강점 + - 4 points: 2 clear strengths - - 3점: 1개의 명확한 강점 + - 3 points: 1 clear strength - - 2점: 강점이 있으나 지속 가능성 의문 + - 2 points: Strengths exist but sustainability questionable - - 1점: 특별한 강점 없음 + - 1 points: No special strengths ' scoring: min: 1 max: 5 criteria: - 5: 3개+ 지속 가능한 경쟁 우위 - 4: 2개 명확한 강점 - 3: 1개 명확한 강점 - 2: 강점 있으나 지속성 의문 - 1: 특별한 강점 없음 + 5: 3+ sustainable competitive advantages + 4: 2 clear strengths + 3: 1 clear strength + 2: Strengths questionable + 1: No special strengths outputSchema: score: number coreCompetencies: string[] diff --git a/backend/app/techniques/definitions/vintage/value-mapping.yaml b/backend/app/techniques/definitions/vintage/value-mapping.yaml index e7f15a4..9119290 100644 --- a/backend/app/techniques/definitions/vintage/value-mapping.yaml +++ b/backend/app/techniques/definitions/vintage/value-mapping.yaml @@ -1,65 +1,62 @@ id: value-mapping name: Value Proposition Mapping -nameKo: 가치 제안 매핑 category: vintage applicableHats: - yellow evaluationDimensions: - A3 - A4 -description: '프로젝트가 제공하는 가치와 고객의 니즈를 매핑하여 +description: 'Technique to analyze the fit of the value proposition by mapping the value provided by the project and customer needs. - 가치 제안의 적합성을 분석하는 기법. - - Alexander Osterwalder의 Value Proposition Canvas 기반. + Based on Alexander Osterwalder''s Value Proposition Canvas. ' -promptTemplate: '## Value Proposition Mapping (가치 제안 매핑) +promptTemplate: '## Value Proposition Mapping - 이 프로젝트의 가치 제안이 고객 니즈와 얼마나 잘 맞는지 분석하세요. + Analyze how well the project''s value proposition fits customer needs. - ### 고객 프로필 분석: + ### Customer Profile Analysis: - 1. **고객의 할 일 (Jobs)**: 고객이 해결하려는 과제는? + 1. **Customer Jobs**: What tasks are customers trying to solve? - 2. **고통점 (Pains)**: 고객의 불편함과 장애물은? + 2. **Pains**: What are the customer''s discomforts and obstacles? - 3. **얻고자 하는 것 (Gains)**: 고객이 원하는 결과와 혜택은? + 3. **Gains**: What results and benefits do customers want? - ### 가치 제안 분석: + ### Value Proposition Analysis: - 1. **제품/서비스**: 어떤 솔루션을 제공하는가? + 1. **Products/Services**: What solution is provided? - 2. **고통 해소제**: 어떤 고통을 줄여주는가? + 2. **Pain Relievers**: What pains are alleviated? - 3. **이득 창출자**: 어떤 이득을 제공하는가? + 3. **Gain Creators**: What gains are provided? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 고객 니즈와 가치 제안이 완벽히 일치 + - 5 points: Perfect match between customer needs and value proposition - - 4점: 대부분의 니즈를 충족하는 가치 제안 + - 4 points: Value proposition meeting most needs - - 3점: 일부 니즈만 충족 + - 3 points: Meets some needs - - 2점: 가치 제안과 니즈 간 갭이 큼 + - 2 points: Large gap between value and needs - - 1점: 가치 제안이 불명확하거나 니즈와 무관 + - 1 points: Value proposition unclear or irrelevant to needs ' scoring: min: 1 max: 5 criteria: - 5: 가치 제안과 니즈 완벽 일치 - 4: 대부분 니즈 충족 - 3: 일부 니즈 충족 - 2: 가치-니즈 간 갭 큼 - 1: 가치 제안 불명확 + 5: Perfect match value-needs + 4: Meets most needs + 3: Meets some needs + 2: Large gap value-needs + 1: Value proposition unclear outputSchema: score: number customerJobs: string[] diff --git a/backend/app/techniques/definitions/vintage/what-if-scenarios.yaml b/backend/app/techniques/definitions/vintage/what-if-scenarios.yaml index 23b0a7e..dc2be20 100644 --- a/backend/app/techniques/definitions/vintage/what-if-scenarios.yaml +++ b/backend/app/techniques/definitions/vintage/what-if-scenarios.yaml @@ -1,6 +1,5 @@ id: what-if-scenarios name: What If Scenarios -nameKo: 가정 시나리오 category: vintage applicableHats: - yellow @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - D1 - D3 -description: '"만약 ~라면?"이라는 가정을 통해 +description: 'Technique to explore new possibilities through the assumption "What if...?". - 새로운 가능성을 탐색하는 기법. - - 제약을 제거하고 가능성을 확장합니다. + Removes constraints and expands possibilities. ' -promptTemplate: '## What If Scenarios 분석 +promptTemplate: '## What If Scenarios Analysis - 프로젝트가 "만약 ~라면?" 사고를 활용했는지 분석하세요. + Analyze if the project utilized "What if...?" thinking. - ### 분석 관점: + ### Analysis Perspectives: - 1. **가정 설정**: 다양한 "What If" 질문을 던졌는가? + 1. **Assumption Setting**: Did it ask various "What If" questions? - 2. **제약 제거**: 현재 제약을 무시하고 상상했는가? + 2. **Constraint Removal**: Did it imagine ignoring current constraints? - 3. **가능성 탐색**: 새로운 가능성을 발견했는가? + 3. **Possibility Exploration**: Did it discover new possibilities? - 4. **실행 연결**: 발견된 가능성을 실행 계획으로 연결했는가? + 4. **Action Connection**: Did it connect discovered possibilities to action plans? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 다양한 What If, 획기적 가능성 발견, 실행 연결 + - 5 points: Various What Ifs, breakthrough possibilities discovered, connected to execution - - 4점: 의미 있는 What If 질문과 가능성 탐색 + - 4 points: Meaningful What If questions and exploration - - 3점: 일부 가상 시나리오 고려 + - 3 points: Some hypothetical scenarios considered - - 2점: 피상적 가정만 + - 2 points: Superficial assumptions only - - 1점: What If 사고 없음 + - 1 points: No What If thinking ' scoring: min: 1 max: 5 criteria: - 5: 다양한 What If, 획기적 가능성, 실행 연결 - 4: 의미 있는 질문과 탐색 - 3: 일부 가상 시나리오 - 2: 피상적 가정만 - 1: What If 없음 + 5: Various What Ifs, breakthrough, execution + 4: Meaningful questions and exploration + 3: Some hypothetical scenarios + 2: Superficial assumptions + 1: No What If thinking outputSchema: score: number whatIfQuestions: string[] diff --git a/backend/app/techniques/definitions/vintage/yes-and-building.yaml b/backend/app/techniques/definitions/vintage/yes-and-building.yaml index 8abbfe4..accda04 100644 --- a/backend/app/techniques/definitions/vintage/yes-and-building.yaml +++ b/backend/app/techniques/definitions/vintage/yes-and-building.yaml @@ -1,6 +1,5 @@ id: yes-and-building name: Yes, And Building -nameKo: 예스-앤드 빌딩 category: vintage applicableHats: - yellow @@ -9,52 +8,50 @@ evaluationDimensions: - A3 - D2 - D3 -description: '즉흥연기에서 유래한 "Yes, and..." 기법. +description: '"Yes, and..." technique derived from improv theater. - 아이디어를 부정하지 않고 수용한 후 - - 그 위에 더 쌓아 올립니다. + Accepts ideas without denial and builds upon them. ' -promptTemplate: '## Yes, And Building 분석 +promptTemplate: '## Yes, And Building Analysis - 프로젝트가 아이디어를 긍정적으로 발전시켰는지 분석하세요. + Analyze if the project developed ideas positively. - ### 분석 관점: + ### Analysis Perspectives: - 1. **수용 태도**: 아이디어를 부정 없이 수용했는가? + 1. **Acceptance Attitude**: Were ideas accepted without denial? - 2. **추가 발전**: 기존 아이디어에 무언가를 더했는가? + 2. **Additional Development**: Was something added to existing ideas? - 3. **협력적 구축**: 팀원들의 아이디어를 쌓아 올렸는가? + 3. **Collaborative Building**: Did they build upon team members'' ideas? - 4. **시너지**: 결합으로 새로운 가치가 창출되었는가? + 4. **Synergy**: Was new value created through combination? - ### 점수 기준: + ### Scoring Criteria: - - 5점: 활발한 Yes-And, 아이디어 시너지, 창의적 결합 + - 5 points: Active Yes-And, idea synergy, creative combination - - 4점: 아이디어 수용 및 발전 + - 4 points: Idea acceptance and development - - 3점: 일부 협력적 발전 + - 3 points: Some collaborative development - - 2점: 주로 개별 작업 + - 2 points: Mostly individual work - - 1점: 아이디어 부정/차단 + - 1 points: Idea denial/blocking ' scoring: min: 1 max: 5 criteria: - 5: 활발한 Yes-And, 시너지 - 4: 아이디어 수용 및 발전 - 3: 일부 협력적 발전 - 2: 주로 개별 작업 - 1: 아이디어 부정 + 5: Active Yes-And, synergy + 4: Idea acceptance/development + 3: Some collaborative development + 2: Mostly individual work + 1: Idea denial outputSchema: score: number ideasAccepted: string[] diff --git a/backend/app/techniques/loader.py b/backend/app/techniques/loader.py index 17a85d7..28da546 100644 --- a/backend/app/techniques/loader.py +++ b/backend/app/techniques/loader.py @@ -1,5 +1,5 @@ from pathlib import Path -from typing import Dict, List, Tuple +from typing import List, Tuple import yaml @@ -36,31 +36,3 @@ def load_techniques( ) return techniques, errors - - -def determine_available_inputs(repo_context: Dict) -> List[str]: - available = {"github"} - if ( - repo_context.get("pdf_context") - or repo_context.get("pdf_text") - or repo_context.get("pdfs") - ): - available.add("pdf") - return sorted(available) - - -def filter_techniques( - techniques: List[TechniqueDefinition], available_inputs: List[str] -) -> List[TechniqueDefinition]: - available = set(available_inputs) - filtered: List[TechniqueDefinition] = [] - - for technique in techniques: - if technique.input_source == "both": - if {"github", "pdf"}.issubset(available): - filtered.append(technique) - continue - if technique.input_source in available: - filtered.append(technique) - - return filtered diff --git a/backend/app/techniques/registry.py b/backend/app/techniques/registry.py index 9a21fc1..a6d7abf 100644 --- a/backend/app/techniques/registry.py +++ b/backend/app/techniques/registry.py @@ -5,8 +5,7 @@ """ import threading -from pathlib import Path -from typing import Dict, List, Optional, Set +from typing import Any, Dict, List, Optional, Set from app.core.logging import logger from app.techniques.loader import DEFAULT_TECHNIQUES_DIR, load_techniques @@ -150,6 +149,15 @@ def list_techniques(self) -> List[TechniqueDefinition]: self._ensure_loaded() return sorted(self._techniques, key=lambda t: t.id) + def get_all_techniques(self) -> List[TechniqueDefinition]: + """Return all loaded techniques without filtering. + + Returns: + List of all 75 technique definitions, sorted by ID. + """ + self._ensure_loaded() + return sorted(self._techniques, key=lambda t: t.id) + def get_technique(self, technique_id: str) -> Optional[TechniqueDefinition]: """Get a technique by its ID. @@ -317,3 +325,50 @@ def list_available_categories() -> List[str]: Sorted list of category names. """ return get_registry().list_categories() + + +def get_all_techniques() -> List[TechniqueDefinition]: + """Get all techniques from the global registry without filtering. + + Returns: + List of all 75 technique definitions, sorted by ID. + """ + return get_registry().get_all_techniques() + + +def has_readme_content(repo_context: Dict[str, Any]) -> bool: + """Check if the repository has README content. + + This utility checks if the repo context contains README content, + which is used for confidence adjustment in technique evaluation. + + Args: + repo_context: The repository context dictionary. + + Returns: + True if the repository has README content, False otherwise. + """ + if not repo_context: + return False + + # Check for readme content in various possible fields + readme_fields = ["readme", "readme_content", "readme_text", "readme_html"] + for field in readme_fields: + content = repo_context.get(field) + if content and isinstance(content, str) and content.strip(): + return True + + # Check if files list contains a README file + files = repo_context.get("files", []) + if files and isinstance(files, list): + readme_names = {"readme", "readme.md", "readme.rst", "readme.txt"} + for file_info in files: + if isinstance(file_info, dict): + filename = file_info.get("name", "").lower() + if filename in readme_names: + return True + elif isinstance(file_info, str): + if file_info.lower() in readme_names: + return True + + return False diff --git a/backend/app/techniques/schema.py b/backend/app/techniques/schema.py index b36de8e..a845fc3 100644 --- a/backend/app/techniques/schema.py +++ b/backend/app/techniques/schema.py @@ -24,7 +24,6 @@ class Config: class TechniqueDefinition(BaseModel): id: str name: str - name_ko: Optional[str] = Field(default=None, alias="nameKo") category: str applicable_hats: List[str] = Field(default_factory=list, alias="applicableHats") evaluation_dimensions: List[str] = Field( @@ -35,21 +34,7 @@ class TechniqueDefinition(BaseModel): scoring: ScoringCriteria = Field(default_factory=ScoringCriteria) output_schema: Dict[str, Any] = Field(default_factory=dict, alias="outputSchema") metadata: TechniqueMetadata = Field(default_factory=TechniqueMetadata) - input_source: Literal["github", "pdf", "both"] = Field( - default="github", alias="requiredSources" - ) + fairthon_source: Optional[str] = Field(default=None, alias="requiredSources") class Config: populate_by_name = True - - def __init__(self, **data): - # Map requiredSources values to input_source - if "requiredSources" in data: - source_map = { - "either": "github", - "pdf": "pdf", - "readme": "github", - "both": "both", - } - data["input_source"] = source_map.get(data.pop("requiredSources"), "github") - super().__init__(**data) diff --git a/backend/tests/conftest.py b/backend/tests/conftest.py index 4a36e96..e2ad7b4 100644 --- a/backend/tests/conftest.py +++ b/backend/tests/conftest.py @@ -5,11 +5,10 @@ import sys from pathlib import Path -# Set required environment variables BEFORE any app imports -# This ensures Settings validation passes when the module is first loaded os.environ.setdefault("GITHUB_CLIENT_ID", "test_client_id") os.environ.setdefault("GITHUB_CLIENT_SECRET", "test_client_secret") -# Add the backend directory to the Python path so we can import 'app' +os.environ.pop("OPENAI_API_KEY", None) + backend_path = Path(__file__).parent.parent sys.path.insert(0, str(backend_path)) diff --git a/backend/tests/fixtures/graph/valid_reactflow_graph.json b/backend/tests/fixtures/graph/valid_reactflow_graph.json index d192a81..7a617af 100644 --- a/backend/tests/fixtures/graph/valid_reactflow_graph.json +++ b/backend/tests/fixtures/graph/valid_reactflow_graph.json @@ -1,6 +1,6 @@ { "graph_schema_version": 2, - "mode": "six_hats", + "mode": "six_sommeliers", "nodes": [ { "id": "start-1", @@ -36,6 +36,6 @@ "animated": false } ], - "description": "Test ReactFlow graph for six_hats mode", + "description": "Test ReactFlow graph for six_sommeliers mode", "meta": {"test": true, "version": "1.0"} } diff --git a/backend/tests/test_auth_scope.py b/backend/tests/test_auth_scope.py index a1019f7..0392e2a 100644 --- a/backend/tests/test_auth_scope.py +++ b/backend/tests/test_auth_scope.py @@ -53,11 +53,11 @@ def test_github_oauth_url_structure(self): assert "state=" in redirect_url assert "scope=" in redirect_url - # Verify state cookie is set set_cookie_header = response.headers.get("set-cookie", "") assert "oauth_state=" in set_cookie_header assert "HttpOnly" in set_cookie_header - assert "Secure" in set_cookie_header + if not settings.FRONTEND_URL.startswith("http://localhost"): + assert "Secure" in set_cookie_header def test_github_oauth_scope_order(self): """Test that scope parameter has correct value with repo first.""" diff --git a/backend/tests/test_bmad_items.py b/backend/tests/test_bmad_items.py new file mode 100644 index 0000000..5163e02 --- /dev/null +++ b/backend/tests/test_bmad_items.py @@ -0,0 +1,82 @@ +"""Tests for BMAD 17-item evaluation canon.""" + +import importlib.util +from pathlib import Path + +import pytest + + +def _load_bmad_module(): + """Load the bmad_items module directly without triggering app imports.""" + backend_path = Path(__file__).parent.parent + module_path = backend_path / "app" / "criteria" / "bmad_items.py" + spec = importlib.util.spec_from_file_location("bmad_items", module_path) + module = importlib.util.module_from_spec(spec) + spec.loader.exec_module(module) + return module + + +bmad = _load_bmad_module() +BMADItem = bmad.BMADItem +BMADCategory = bmad.BMADCategory +BMAD_ITEMS = bmad.BMAD_ITEMS +BMAD_CATEGORIES = bmad.BMAD_CATEGORIES +get_item = bmad.get_item +list_items = bmad.list_items +get_items_by_category = bmad.get_items_by_category +get_category = bmad.get_category +get_max_total = bmad.get_max_total +get_category_max = bmad.get_category_max + + +class TestBMADItems: + def test_total_items_count(self): + assert len(BMAD_ITEMS) == 17 + + def test_total_max_score_is_100(self): + assert sum(item.max_score for item in BMAD_ITEMS.values()) == 100 + + def test_category_a_sum_is_25(self): + assert get_category_max("A") == 25 + + def test_category_b_sum_is_25(self): + assert get_category_max("B") == 25 + + def test_category_c_sum_is_30(self): + assert get_category_max("C") == 30 + + def test_category_d_sum_is_20(self): + assert get_category_max("D") == 20 + + def test_get_item_a1(self): + item = get_item("A1") + assert item.item_id == "A1" + assert item.max_score == 7 + assert item.category == "A" + + def test_all_items_have_rubric(self): + for item in BMAD_ITEMS.values(): + assert len(item.rubric) > 0, f"{item.item_id} has empty rubric" + + def test_list_items_order(self): + items = list_items() + assert len(items) == 17 + assert items[0].item_id == "A1" + assert items[-1].item_id == "D4" + + def test_get_items_by_category(self): + a_items = get_items_by_category("A") + assert len(a_items) == 4 + c_items = get_items_by_category("C") + assert len(c_items) == 5 + + def test_get_max_total(self): + assert get_max_total() == 100 + + def test_invalid_item_raises(self): + with pytest.raises(KeyError): + get_item("Z99") + + def test_four_categories(self): + assert len(BMAD_CATEGORIES) == 4 + assert set(BMAD_CATEGORIES.keys()) == {"A", "B", "C", "D"} diff --git a/backend/tests/test_graph_api.py b/backend/tests/test_graph_api.py index 0462363..d5e5806 100644 --- a/backend/tests/test_graph_api.py +++ b/backend/tests/test_graph_api.py @@ -16,9 +16,9 @@ from fastapi.testclient import TestClient from app.main import app +from app.graph.graph_factory import EvaluationMode from app.models.graph import ( GRAPH_SCHEMA_VERSION, - EvaluationMode, ReactFlowGraph, TraceEvent, ModeResponse, @@ -50,15 +50,15 @@ def mock_token(): @pytest.fixture -def mock_evaluation_six_hats(): - """Mock evaluation document for six_hats mode.""" +def mock_evaluation_six_sommeliers(): + """Mock evaluation document for six_sommeliers mode.""" return { "_id": "eval123", "user_id": "user123", "repo_context": {"repo_url": "https://github.com/test/repo"}, "criteria": "basic", "status": "completed", - "mode": "six_hats", + "mode": "six_sommeliers", "created_at": datetime.now(timezone.utc), "updated_at": datetime.now(timezone.utc), } @@ -89,66 +89,68 @@ def auth_headers(mock_token): class TestAuthentication: - """Test authentication requirements for graph endpoints.""" + """Test authentication requirements for graph endpoints. - def test_get_graph_without_auth_returns_401(self): - """Test that graph endpoint requires authentication.""" - response = client.get("/api/evaluate/eval123/graph") - assert response.status_code == 401 + Note: graph, timeline, and mode endpoints use get_optional_user + (not get_current_user) to support public demo evaluations. + For non-public evaluations, _check_ownership raises CorkedError + when user is None. + """ - def test_get_timeline_without_auth_returns_401(self): - """Test that timeline endpoint requires authentication.""" - response = client.get("/api/evaluate/eval123/graph/timeline") - assert response.status_code == 401 + def test_check_ownership_requires_auth_for_non_public(self): + """Test that _check_ownership raises CorkedError when user is None for non-public evaluations.""" + from app.api.routes.graph import _check_ownership - def test_get_mode_without_auth_returns_401(self): - """Test that mode endpoint requires authentication.""" - response = client.get("/api/evaluate/eval123/graph/mode") - assert response.status_code == 401 + evaluation = {"user_id": "some_user"} + with pytest.raises(CorkedError) as exc_info: + _check_ownership(evaluation, None, "non_public_eval_id") + assert "Authentication required" in str(exc_info.value.detail) + def test_check_ownership_allows_public_demo_without_auth(self): + """Test that public demo evaluations can be accessed without authentication.""" + from app.api.routes.graph import _check_ownership, PUBLIC_DEMO_EVALUATIONS -# Authorization Tests + evaluation = {"user_id": "some_user"} + demo_id = next(iter(PUBLIC_DEMO_EVALUATIONS)) + _check_ownership(evaluation, None, demo_id) + def test_check_ownership_allows_authenticated_owner(self): + """Test that authenticated owner can access their evaluation.""" + from app.api.routes.graph import _check_ownership -class TestAuthorization: - """Test authorization checks for graph endpoints.""" + user = MagicMock(id="user123") + evaluation = {"user_id": "user123"} + _check_ownership(evaluation, user, "any_eval_id") - def test_get_graph_wrong_user_returns_403(self): - """Test that accessing another user's evaluation returns 403.""" - # Test the underlying function directly - from app.api.routes.graph import _check_ownership - evaluation = {"user_id": "different_user"} - user = MagicMock(id="current_user") +# Authorization Tests - with pytest.raises(CorkedError) as exc_info: - _check_ownership(evaluation, user) - assert "Access denied" in str(exc_info.value.detail) +class TestAuthorization: + """Test authorization checks for graph endpoints.""" - def test_get_timeline_wrong_user_returns_403(self): - """Test that timeline endpoint checks ownership.""" + def test_wrong_user_returns_403(self): + """Test that accessing another user's evaluation returns 403.""" from app.api.routes.graph import _check_ownership evaluation = {"user_id": "different_user"} user = MagicMock(id="current_user") with pytest.raises(CorkedError) as exc_info: - _check_ownership(evaluation, user) + _check_ownership(evaluation, user, "eval123") assert "Access denied" in str(exc_info.value.detail) - def test_get_mode_wrong_user_returns_403(self): - """Test that mode endpoint checks ownership.""" + def test_unauthenticated_non_public_returns_auth_error(self): + """Test that unauthenticated access to non-public evaluation raises CorkedError.""" from app.api.routes.graph import _check_ownership - evaluation = {"user_id": "different_user"} - user = MagicMock(id="current_user") + evaluation = {"user_id": "some_user"} with pytest.raises(CorkedError) as exc_info: - _check_ownership(evaluation, user) + _check_ownership(evaluation, None, "non_public_eval") - assert "Access denied" in str(exc_info.value.detail) + assert "Authentication required" in str(exc_info.value.detail) # 404 Not Found Tests @@ -206,13 +208,13 @@ class TestSchemaValidation: def test_react_flow_graph_model_has_required_fields(self): """Test that ReactFlowGraph model has all required fields.""" graph = ReactFlowGraph( - mode=EvaluationMode.SIX_HATS.value, + mode=EvaluationMode.SIX_SOMMELIERS.value, nodes=[], edges=[], ) assert graph.graph_schema_version == GRAPH_SCHEMA_VERSION - assert graph.mode == EvaluationMode.SIX_HATS.value + assert graph.mode == EvaluationMode.SIX_SOMMELIERS.value assert isinstance(graph.nodes, list) assert isinstance(graph.edges, list) @@ -235,11 +237,11 @@ def test_trace_event_model_has_required_fields(self): def test_mode_response_model_has_required_fields(self): """Test that ModeResponse model has all required fields.""" response = ModeResponse( - mode=EvaluationMode.SIX_HATS.value, + mode=EvaluationMode.SIX_SOMMELIERS.value, evaluation_id="eval123", ) - assert response.mode == EvaluationMode.SIX_HATS.value + assert response.mode == EvaluationMode.SIX_SOMMELIERS.value assert response.evaluation_id == "eval123" @@ -249,14 +251,14 @@ def test_mode_response_model_has_required_fields(self): class TestGraphBuilder: """Test graph builder service functions.""" - def test_build_six_hats_topology_returns_valid_graph(self): - """Test that six_hats topology builder returns valid ReactFlowGraph.""" - from app.services.graph_builder import build_six_hats_topology + def test_build_six_sommeliers_topology_returns_valid_graph(self): + """Test that six_sommeliers topology builder returns valid ReactFlowGraph.""" + from app.services.graph_builder import build_six_sommeliers_topology - graph = build_six_hats_topology() + graph = build_six_sommeliers_topology() assert isinstance(graph, ReactFlowGraph) - assert graph.mode == EvaluationMode.SIX_HATS.value + assert graph.mode == EvaluationMode.SIX_SOMMELIERS.value assert graph.graph_schema_version == GRAPH_SCHEMA_VERSION assert len(graph.nodes) > 0 assert len(graph.edges) > 0 @@ -285,11 +287,14 @@ def test_build_full_techniques_topology_returns_valid_graph(self): assert "technique_group" in node_types or "synthesis" in node_types assert "end" in node_types - def test_six_hats_has_expected_sommelier_nodes(self): - """Test that six_hats topology includes all expected sommelier nodes.""" - from app.services.graph_builder import build_six_hats_topology, SOMMELIER_CONFIG + def test_six_sommeliers_has_expected_sommelier_nodes(self): + """Test that six_sommeliers topology includes all expected sommelier nodes.""" + from app.services.graph_builder import ( + build_six_sommeliers_topology, + SOMMELIER_CONFIG, + ) - graph = build_six_hats_topology() + graph = build_six_sommeliers_topology() node_ids = {node.id for node in graph.nodes} # Check all sommeliers are present @@ -317,12 +322,12 @@ def test_full_techniques_has_expected_technique_groups(self): class TestSnapshotStability: """Test that topology structure is consistent across calls.""" - def test_six_hats_topology_structure_is_stable(self): - """Test that six_hats topology produces consistent structure.""" - from app.services.graph_builder import build_six_hats_topology + def test_six_sommeliers_topology_structure_is_stable(self): + """Test that six_sommeliers topology produces consistent structure.""" + from app.services.graph_builder import build_six_sommeliers_topology # Build multiple graphs - graphs = [build_six_hats_topology() for _ in range(3)] + graphs = [build_six_sommeliers_topology() for _ in range(3)] # All graphs should have same structure first = graphs[0] @@ -360,14 +365,23 @@ def test_full_techniques_topology_structure_is_stable(self): class TestModeDetection: """Test evaluation mode detection.""" - def test_determine_mode_returns_six_hats_for_six_hats_mode(self): - """Test that _determine_mode returns SIX_HATS for six_hats mode.""" + def test_determine_mode_returns_six_sommeliers_for_six_sommeliers_mode(self): + """Test that _determine_mode returns SIX_SOMMELIERS for six_sommeliers mode.""" + from app.api.routes.graph import _determine_mode + + evaluation = {"mode": "six_sommeliers"} + mode = _determine_mode(evaluation) + + assert mode == EvaluationMode.SIX_SOMMELIERS + + def test_determine_mode_returns_six_sommeliers_for_evaluation_mode_field(self): + """Test that _determine_mode checks evaluation_mode field first.""" from app.api.routes.graph import _determine_mode - evaluation = {"mode": "six_hats"} + evaluation = {"evaluation_mode": "six_sommeliers", "mode": "full_techniques"} mode = _determine_mode(evaluation) - assert mode == EvaluationMode.SIX_HATS + assert mode == EvaluationMode.SIX_SOMMELIERS def test_determine_mode_returns_full_techniques_for_full_techniques_mode(self): """Test that _determine_mode returns FULL_TECHNIQUES for full_techniques mode.""" @@ -378,11 +392,11 @@ def test_determine_mode_returns_full_techniques_for_full_techniques_mode(self): assert mode == EvaluationMode.FULL_TECHNIQUES - def test_determine_mode_defaults_to_six_hats(self): - """Test that _determine_mode defaults to SIX_HATS when mode not specified.""" + def test_determine_mode_defaults_to_six_sommeliers(self): + """Test that _determine_mode defaults to SIX_SOMMELIERS when mode not specified.""" from app.api.routes.graph import _determine_mode evaluation = {} mode = _determine_mode(evaluation) - assert mode == EvaluationMode.SIX_HATS + assert mode == EvaluationMode.SIX_SOMMELIERS diff --git a/backend/tests/test_graph_cache.py b/backend/tests/test_graph_cache.py index 4d6606b..de554df 100644 --- a/backend/tests/test_graph_cache.py +++ b/backend/tests/test_graph_cache.py @@ -18,16 +18,18 @@ class TestCacheKeyGeneration: def test_generate_cache_key_basic(self): - key = generate_cache_key("eval_abc123", "six_hats", "2d") - assert key == "eval_abc123:six_hats:2d:v2" + key = generate_cache_key("eval_abc123", "six_sommeliers", "2d") + assert key == "eval_abc123:six_sommeliers:2d:v2" def test_generate_cache_key_3d(self): key = generate_cache_key("eval_xyz789", "basic", "3d") assert key == "eval_xyz789:basic:3d:v2" def test_generate_cache_key_custom_version(self): - key = generate_cache_key("eval_abc123", "six_hats", "2d", schema_version=3) - assert key == "eval_abc123:six_hats:2d:v3" + key = generate_cache_key( + "eval_abc123", "six_sommeliers", "2d", schema_version=3 + ) + assert key == "eval_abc123:six_sommeliers:2d:v3" def test_generate_cache_key_stability(self): key1 = generate_cache_key("eval_abc", "mode1", "2d") diff --git a/backend/tests/test_graph_contracts.py b/backend/tests/test_graph_contracts.py index 0d8c954..e8ce2e2 100644 --- a/backend/tests/test_graph_contracts.py +++ b/backend/tests/test_graph_contracts.py @@ -14,9 +14,9 @@ import pytest from pydantic import ValidationError +from app.graph.graph_factory import EvaluationMode from app.models.graph import ( GRAPH_SCHEMA_VERSION, - EvaluationMode, ReactFlowNode, ReactFlowEdge, ReactFlowGraph, @@ -35,26 +35,35 @@ class TestEvaluationMode: def test_enum_values(self): """Test that EvaluationMode has correct canonical values.""" - assert EvaluationMode.SIX_HATS.value == "six_hats" + assert EvaluationMode.SIX_SOMMELIERS.value == "six_sommeliers" + assert EvaluationMode.GRAND_TASTING.value == "grand_tasting" assert EvaluationMode.FULL_TECHNIQUES.value == "full_techniques" def test_enum_comparison(self): """Test enum value comparison.""" - assert EvaluationMode.SIX_HATS == EvaluationMode("six_hats") + assert EvaluationMode.SIX_SOMMELIERS == EvaluationMode("six_sommeliers") + assert EvaluationMode.GRAND_TASTING == EvaluationMode("grand_tasting") assert EvaluationMode.FULL_TECHNIQUES == EvaluationMode("full_techniques") def test_enum_from_string(self): """Test creating enum from string values.""" - mode1 = EvaluationMode("six_hats") - mode2 = EvaluationMode("full_techniques") - assert mode1 == EvaluationMode.SIX_HATS - assert mode2 == EvaluationMode.FULL_TECHNIQUES + mode1 = EvaluationMode("six_sommeliers") + mode2 = EvaluationMode("grand_tasting") + mode3 = EvaluationMode("full_techniques") + assert mode1 == EvaluationMode.SIX_SOMMELIERS + assert mode2 == EvaluationMode.GRAND_TASTING + assert mode3 == EvaluationMode.FULL_TECHNIQUES def test_invalid_enum_value(self): """Test that invalid enum values raise ValueError.""" with pytest.raises(ValueError): EvaluationMode("invalid_mode") + def test_old_six_hats_value_rejected(self): + """Test that old 'six_hats' value is rejected (renamed to six_sommeliers).""" + with pytest.raises(ValueError): + EvaluationMode("six_hats") + class TestReactFlowGraph: """Tests for ReactFlowGraph 2D models.""" @@ -111,13 +120,13 @@ def test_valid_reactflow_graph(self): target="node-2", ) graph = ReactFlowGraph( - mode="six_hats", + mode="six_sommeliers", nodes=[node], edges=[edge], description="Test graph", ) assert graph.graph_schema_version == GRAPH_SCHEMA_VERSION - assert graph.mode == "six_hats" + assert graph.mode == "six_sommeliers" assert len(graph.nodes) == 1 assert len(graph.edges) == 1 assert graph.description == "Test graph" @@ -130,10 +139,10 @@ def test_reactflow_graph_from_fixture(self): graph = ReactFlowGraph(**data) assert graph.graph_schema_version == 2 - assert graph.mode == "six_hats" + assert graph.mode == "six_sommeliers" assert len(graph.nodes) == 3 assert len(graph.edges) == 2 - assert graph.description == "Test ReactFlow graph for six_hats mode" + assert graph.description == "Test ReactFlow graph for six_sommeliers mode" def test_reactflow_node_missing_id(self): """Test ReactFlowNode fails without id.""" @@ -306,14 +315,14 @@ def test_valid_payload(self): payload = Graph3DPayload( evaluation_id="eval_123", - mode="six_hats", + mode="six_sommeliers", nodes=[node], edges=[edge], metadata=metadata, ) assert payload.graph_schema_version == GRAPH_SCHEMA_VERSION assert payload.evaluation_id == "eval_123" - assert payload.mode == "six_hats" + assert payload.mode == "six_sommeliers" def test_payload_from_fixture(self): """Test loading valid Graph3DPayload from golden fixture.""" @@ -391,7 +400,7 @@ def test_payload_missing_evaluation_id(self): with pytest.raises(ValidationError): Graph3DPayload( - mode="six_hats", + mode="invalid_mode_for_test", nodes=[node], edges=[], metadata=metadata, @@ -414,7 +423,7 @@ def test_reactflow_default_version(self): data={}, ) graph = ReactFlowGraph( - mode="six_hats", + mode="six_sommeliers", nodes=[node], edges=[], ) @@ -449,9 +458,9 @@ def test_3d_payload_default_version(self): payload = Graph3DPayload( evaluation_id="eval_123", - mode="six_hats", + mode="six_sommeliers", nodes=[node], - edges=[edge], + edges=[], metadata=metadata, ) assert payload.graph_schema_version == 2 @@ -466,7 +475,7 @@ def test_explicit_version_override(self): ) graph = ReactFlowGraph( graph_schema_version=3, - mode="six_hats", + mode="six_sommeliers", nodes=[node], edges=[], ) @@ -496,7 +505,7 @@ def test_version_mismatch_payload_vs_metadata(self): Graph3DPayload( graph_schema_version=3, evaluation_id="eval_123", - mode="six_hats", + mode="six_sommeliers", nodes=[node], edges=[], metadata=metadata, diff --git a/backend/tests/test_graph_factory.py b/backend/tests/test_graph_factory.py index 208c6d1..7ea29a9 100644 --- a/backend/tests/test_graph_factory.py +++ b/backend/tests/test_graph_factory.py @@ -24,6 +24,9 @@ def test_six_sommeliers_value(self): def test_grand_tasting_value(self): assert EvaluationMode.GRAND_TASTING.value == "grand_tasting" + def test_full_techniques_value(self): + assert EvaluationMode.FULL_TECHNIQUES.value == "full_techniques" + class TestListAvailableModes: def test_returns_both_modes(self): diff --git a/backend/tests/test_multi_mode.py b/backend/tests/test_multi_mode.py index ec61293..c081fe7 100644 --- a/backend/tests/test_multi_mode.py +++ b/backend/tests/test_multi_mode.py @@ -109,18 +109,32 @@ def builder2(eval_id: str): class TestModeConstants: - def test_six_hats_constant(self): - from app.models.graph import EvaluationMode + def test_six_sommeliers_constant(self): + from app.graph.graph_factory import EvaluationMode - assert EvaluationMode.SIX_HATS.value == "six_hats" + assert EvaluationMode.SIX_SOMMELIERS.value == "six_sommeliers" + + def test_grand_tasting_constant(self): + from app.graph.graph_factory import EvaluationMode + + assert EvaluationMode.GRAND_TASTING.value == "grand_tasting" def test_full_techniques_constant(self): - from app.models.graph import EvaluationMode + from app.graph.graph_factory import EvaluationMode assert EvaluationMode.FULL_TECHNIQUES.value == "full_techniques" def test_evaluation_mode_is_string_enum(self): - from app.models.graph import EvaluationMode + from app.graph.graph_factory import EvaluationMode - assert isinstance(EvaluationMode.SIX_HATS.value, str) + assert isinstance(EvaluationMode.SIX_SOMMELIERS.value, str) + assert isinstance(EvaluationMode.GRAND_TASTING.value, str) assert isinstance(EvaluationMode.FULL_TECHNIQUES.value, str) + + def test_old_six_hats_value_rejected(self): + """Test that old 'six_hats' value is rejected.""" + from app.graph.graph_factory import EvaluationMode + import pytest + + with pytest.raises(ValueError): + EvaluationMode("six_hats") diff --git a/backend/tests/test_technique_loading.py b/backend/tests/test_technique_loading.py new file mode 100644 index 0000000..9d21513 --- /dev/null +++ b/backend/tests/test_technique_loading.py @@ -0,0 +1,284 @@ +"""Tests for Issue #224 - 75기법 GitHub 재분류 + schema.py requiredSources 수정 + +This module tests: +1. All 75 techniques load without source-based exclusion +2. fairthon_source field preserves original YAML values +3. input_source field no longer exists on TechniqueDefinition +4. has_readme_content() utility function +5. get_all_techniques() returns all loaded techniques +6. filter_techniques and determine_available_inputs are no longer importable +""" + +import pytest + + +class TestTechniqueLoading: + """Tests that all 75 techniques load correctly.""" + + def test_all_75_techniques_load(self): + """Test that all 75 techniques load without source-based exclusion.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + + assert len(techniques) == 75, f"Expected 75 techniques, got {len(techniques)}" + + def test_get_all_techniques_returns_all_75(self): + """Test that get_all_techniques() returns all 75 techniques.""" + from app.techniques.registry import ( + TechniqueRegistry, + get_all_techniques, + ) + + TechniqueRegistry.reset() + + techniques = get_all_techniques() + + assert len(techniques) == 75, f"Expected 75 techniques, got {len(techniques)}" + + def test_technique_registry_get_all_techniques(self): + """Test TechniqueRegistry.get_all_techniques() method.""" + from app.techniques.registry import TechniqueRegistry + + TechniqueRegistry.reset() + registry = TechniqueRegistry() + + techniques = registry.get_all_techniques() + + assert len(techniques) == 75, f"Expected 75 techniques, got {len(techniques)}" + + def test_techniques_sorted_by_id(self): + """Test that techniques are sorted by ID.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + ids = [t.id for t in techniques] + + assert ids == sorted(ids), "Techniques should be sorted by ID" + + +class TestFairthonSourceField: + """Tests for the fairthon_source field.""" + + def test_fairthon_source_field_exists(self): + """Test that fairthon_source field exists on TechniqueDefinition.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + + for technique in techniques: + assert hasattr(technique, "fairthon_source"), ( + f"Technique {technique.id} missing fairthon_source field" + ) + + def test_fairthon_source_preserves_original_values(self): + """Test that fairthon_source preserves original YAML values.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + + source_values = set() + for technique in techniques: + if technique.fairthon_source: + source_values.add(technique.fairthon_source) + + valid_values = {"either", "both", "pdf", "readme", "pdf_only", "readme_only"} + + for value in source_values: + assert value in valid_values or value in [ + "either", + "both", + "pdf", + "readme", + ], f"Unexpected fairthon_source value: {value}" + + def test_fairthon_source_from_yaml_requiredSources(self): + """Test that fairthon_source is populated from requiredSources YAML field.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + + by_source = {} + for technique in techniques: + source = technique.fairthon_source or "none" + by_source.setdefault(source, []).append(technique.id) + + assert len(by_source) > 0, "No fairthon_source values found" + + +class TestInputSourceRemoved: + """Tests that input_source field has been removed.""" + + def test_input_source_field_removed(self): + """Test that input_source field no longer exists on TechniqueDefinition.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + + for technique in techniques: + assert not hasattr(technique, "input_source"), ( + f"Technique {technique.id} should not have input_source field" + ) + + def test_technique_definition_no_input_source_attribute(self): + """Test that accessing input_source raises AttributeError.""" + from app.techniques.registry import get_all_techniques + + techniques = get_all_techniques() + technique = techniques[0] + + with pytest.raises(AttributeError): + _ = technique.input_source + + +class TestRemovedFunctionsNotImportable: + """Tests that removed functions are no longer importable.""" + + def test_filter_techniques_not_importable(self): + """Test that filter_techniques is no longer importable from loader.""" + with pytest.raises(ImportError): + from app.techniques.loader import filter_techniques # noqa: F401 + + def test_determine_available_inputs_not_importable(self): + """Test that determine_available_inputs is no longer importable from loader.""" + with pytest.raises(ImportError): + from app.techniques.loader import determine_available_inputs # noqa: F401 + + def test_filter_techniques_not_in_module_all(self): + """Test that filter_techniques is not in __all__.""" + from app.techniques import __all__ + + assert "filter_techniques" not in __all__, ( + "filter_techniques should not be in __all__" + ) + + def test_determine_available_inputs_not_in_module_all(self): + """Test that determine_available_inputs is not in __all__.""" + from app.techniques import __all__ + + assert "determine_available_inputs" not in __all__, ( + "determine_available_inputs should not be in __all__" + ) + + +class TestHasReadmeContent: + """Tests for the has_readme_content utility function.""" + + def test_has_readme_content_returns_true_with_readme(self): + """Test that has_readme_content returns True when README exists.""" + from app.techniques.registry import has_readme_content + + repo_context = {"readme": "# Project README\n\nThis is a test project."} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_returns_true_with_readme_content(self): + """Test that has_readme_content returns True with readme_content field.""" + from app.techniques.registry import has_readme_content + + repo_context = {"readme_content": "# Test\n\nContent here."} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_returns_true_with_readme_text(self): + """Test that has_readme_content returns True with readme_text field.""" + from app.techniques.registry import has_readme_content + + repo_context = {"readme_text": "# Test\n\nContent here."} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_returns_true_with_readme_html(self): + """Test that has_readme_content returns True with readme_html field.""" + from app.techniques.registry import has_readme_content + + repo_context = {"readme_html": "

Test

Content

"} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_returns_false_without_readme(self): + """Test that has_readme_content returns False when no README.""" + from app.techniques.registry import has_readme_content + + repo_context = {"files": ["main.py", "requirements.txt"]} + + assert has_readme_content(repo_context) is False + + def test_has_readme_content_returns_false_empty_context(self): + """Test that has_readme_content returns False with empty context.""" + from app.techniques.registry import has_readme_content + + assert has_readme_content({}) is False + assert has_readme_content(None) is False # type: ignore[arg-type] + + def test_has_readme_content_returns_false_empty_readme(self): + """Test that has_readme_content returns False with empty README string.""" + from app.techniques.registry import has_readme_content + + repo_context = {"readme": " "} + + assert has_readme_content(repo_context) is False + + def test_has_readme_content_detects_from_files_list(self): + """Test that has_readme_content detects README from files list.""" + from app.techniques.registry import has_readme_content + + repo_context = { + "files": [ + {"name": "README.md", "path": "/README.md"}, + {"name": "main.py", "path": "/main.py"}, + ] + } + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_detects_from_string_files_list(self): + """Test that has_readme_content detects README from string files list.""" + from app.techniques.registry import has_readme_content + + repo_context = {"files": ["README.md", "main.py", "requirements.txt"]} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_case_insensitive(self): + """Test that has_readme_content is case insensitive.""" + from app.techniques.registry import has_readme_content + + repo_context = {"files": ["readme.MD"]} + + assert has_readme_content(repo_context) is True + + def test_has_readme_content_various_formats(self): + """Test that has_readme_content detects various README formats.""" + from app.techniques.registry import has_readme_content + + formats = ["README.rst", "readme.txt", "README"] + + for fmt in formats: + repo_context = {"files": [fmt]} + assert has_readme_content(repo_context) is True, f"Failed for {fmt}" + + +class TestNewExports: + """Tests for new exports from techniques module.""" + + def test_get_all_techniques_exported(self): + """Test that get_all_techniques is exported from techniques module.""" + from app.techniques import get_all_techniques as exported_func + + techniques = exported_func() + assert len(techniques) == 75 + + def test_has_readme_content_exported(self): + """Test that has_readme_content is exported from techniques module.""" + from app.techniques import has_readme_content as exported_func + + result = exported_func({"readme": "# Test"}) + assert result is True + + def test_new_functions_in_all(self): + """Test that new functions are in __all__.""" + from app.techniques import __all__ + + assert "get_all_techniques" in __all__ + assert "has_readme_content" in __all__ diff --git a/backend/tests/test_techniques_loader.py b/backend/tests/test_techniques_loader.py index 47ae555..bc630a6 100644 --- a/backend/tests/test_techniques_loader.py +++ b/backend/tests/test_techniques_loader.py @@ -1,10 +1,6 @@ from pathlib import Path -from app.techniques.loader import ( - determine_available_inputs, - filter_techniques, - load_techniques, -) +from app.techniques.loader import load_techniques from app.techniques.schema import TechniqueDefinition @@ -28,39 +24,3 @@ def test_load_techniques_schema_validation_error(tmp_path: Path): techniques, errors = load_techniques(tmp_path) assert techniques == [] assert errors - - -def test_filter_techniques_by_input_source(): - from app.techniques.schema import ScoringCriteria - - techniques = [ - TechniqueDefinition( - id="t1", - name="Test Technique 1", - category="structure", - input_source="github", - scoring=ScoringCriteria(min=1, max=5, criteria={}, weight=1.0), - output_schema={"score": "integer"}, - prompt_template="x", - ), - TechniqueDefinition( - id="t2", - name="Test Technique 2", - category="structure", - input_source="both", - scoring=ScoringCriteria(min=1, max=5, criteria={}, weight=1.0), - output_schema={"score": "integer"}, - prompt_template="y", - ), - ] - - github_only = filter_techniques(techniques, ["github"]) - assert [t.id for t in github_only] == ["t1"] - - both_inputs = filter_techniques(techniques, ["github", "pdf"]) - assert [t.id for t in both_inputs] == ["t1", "t2"] - - -def test_determine_available_inputs_from_repo_context(): - assert determine_available_inputs({}) == ["github"] - assert determine_available_inputs({"pdf_context": "x"}) == ["github", "pdf"] diff --git a/backend/tests/test_yaml_english.py b/backend/tests/test_yaml_english.py new file mode 100644 index 0000000..77415a5 --- /dev/null +++ b/backend/tests/test_yaml_english.py @@ -0,0 +1,81 @@ +"""Tests for English YAML technique definitions.""" + +import re +from pathlib import Path + +import pytest +import yaml + +KOREAN_PATTERN = re.compile( + r"[\uac00-\ud7af\u1100-\u11ff\u3130-\u318f\ua960-\ua97f\ud7b0-\ud7ff]" +) + +DEFINITIONS_DIR = Path(__file__).parent.parent / "app" / "techniques" / "definitions" +VALID_CATEGORIES = { + "aroma", + "palate", + "body", + "finish", + "balance", + "vintage", + "terroir", + "cellar", +} + + +def load_yaml_files(): + yaml_files = list(DEFINITIONS_DIR.glob("**/*.yaml")) + list( + DEFINITIONS_DIR.glob("**/*.yml") + ) + techniques = [] + errors = [] + + for path in sorted(yaml_files): + try: + raw = yaml.safe_load(path.read_text(encoding="utf-8")) + if not isinstance(raw, dict): + raise ValueError(f"Technique file {path.name} must define a mapping") + techniques.append(raw) + except Exception as exc: + errors.append(f"{path.name}: {exc}") + + return techniques, errors + + +class TestYAMLEnglish: + @pytest.fixture(autouse=True) + def setup(self): + self.techniques, self.errors = load_yaml_files() + + def test_all_75_load(self): + assert len(self.techniques) == 75, ( + f"Expected 75, got {len(self.techniques)}, errors: {self.errors}" + ) + + def test_no_load_errors(self): + assert len(self.errors) == 0, f"Load errors: {self.errors}" + + def test_no_korean_in_descriptions(self): + for tech in self.techniques: + description = tech.get("description", "") + assert not KOREAN_PATTERN.search(description), ( + f"{tech.get('id')} has Korean in description" + ) + + def test_no_korean_in_prompts(self): + for tech in self.techniques: + prompt = tech.get("promptTemplate", "") + assert not KOREAN_PATTERN.search(prompt), ( + f"{tech.get('id')} has Korean in promptTemplate" + ) + + def test_no_name_ko_field(self): + for tech in self.techniques: + assert "nameKo" not in tech, f"{tech.get('id')} still has nameKo field" + + def test_categories_are_wine_themed(self): + for tech in self.techniques: + category = tech.get("category", "") + assert category in VALID_CATEGORIES, ( + f"{tech.get('id')} has non-wine category: {category}" + ) diff --git a/frontend/src/types/index.ts b/frontend/src/types/index.ts index a4c6b2b..1835ba0 100644 --- a/frontend/src/types/index.ts +++ b/frontend/src/types/index.ts @@ -2,7 +2,7 @@ export type EvaluationStatus = 'pending' | 'processing' | 'completed' | 'failed' export type CriteriaType = 'basic' | 'hackathon' | 'academic' | 'custom'; -export type EvaluationMode = 'six_sommeliers' | 'grand_tasting'; +export type EvaluationMode = 'six_sommeliers' | 'grand_tasting' | 'full_techniques'; export interface EvaluationRequest { repoUrl: string; From cf3c9fbeabc505eaf82ecd4fe4147d6dc63457f4 Mon Sep 17 00:00:00 2001 From: ComBba Date: Mon, 9 Feb 2026 16:08:14 +0900 Subject: [PATCH 2/2] feat(group-a): EvaluationState extension + Hat-BMAD mappings (#228, #229) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - #228: Extend EvaluationState with full_techniques fields - Add 14 new state fields (evaluation_mode, quality_gate, category_scores, etc.) - Extend ItemScore: relax score constraint (ge=0), add 8 optional fields - Create constants.py with quality gate logic (PASS/CONCERNS/FAIL/INCOMPLETE) - Add merge_hat_contributions reducer - #229: Create hat and technique mapping modules - hat_mappings.py: Hat enum, Hat→BMAD items, reverse ITEM→Hats lookup - technique_mappings.py: 75 technique→BMAD item mappings - Mode filtering: full_techniques(75) > six_sommeliers(P0+P1) > grand_tasting(P0) - All 17 BMAD items covered by at least one hat Closes #228, Closes #229 --- backend/app/constants.py | 13 ++ backend/app/criteria/hat_mappings.py | 86 ++++++++++ backend/app/criteria/technique_mappings.py | 191 +++++++++++++++++++++ backend/app/graph/state.py | 40 +++++ backend/app/models/graph.py | 28 ++- backend/tests/test_hat_mappings.py | 74 ++++++++ backend/tests/test_item_score_model.py | 104 +++++++++++ backend/tests/test_quality_gate.py | 50 ++++++ backend/tests/test_technique_mappings.py | 102 ++++++++++- 9 files changed, 686 insertions(+), 2 deletions(-) create mode 100644 backend/app/constants.py create mode 100644 backend/app/criteria/hat_mappings.py create mode 100644 backend/app/criteria/technique_mappings.py create mode 100644 backend/tests/test_hat_mappings.py create mode 100644 backend/tests/test_item_score_model.py create mode 100644 backend/tests/test_quality_gate.py diff --git a/backend/app/constants.py b/backend/app/constants.py new file mode 100644 index 0000000..c785bdb --- /dev/null +++ b/backend/app/constants.py @@ -0,0 +1,13 @@ +PASS_THRESHOLD = 70 +CONCERNS_THRESHOLD = 50 +COVERAGE_THRESHOLD = 0.5 + + +def get_quality_gate(normalized_score: float, coverage_rate: float) -> str: + if coverage_rate < COVERAGE_THRESHOLD: + return "INCOMPLETE" + if normalized_score >= PASS_THRESHOLD: + return "PASS" + if normalized_score >= CONCERNS_THRESHOLD: + return "CONCERNS" + return "FAIL" diff --git a/backend/app/criteria/hat_mappings.py b/backend/app/criteria/hat_mappings.py new file mode 100644 index 0000000..c653397 --- /dev/null +++ b/backend/app/criteria/hat_mappings.py @@ -0,0 +1,86 @@ +"""Six Thinking Hats to BMAD item mappings. + +This module maps Edward de Bono's Six Thinking Hats to the 17 BMAD evaluation items, +enabling multi-perspective code evaluation. +""" + +from enum import Enum +from typing import Dict, List + + +class Hat(str, Enum): + WHITE = "white" # Facts & Data + RED = "red" # Emotions & Feelings + BLACK = "black" # Caution & Risk + YELLOW = "yellow" # Optimism & Benefits + GREEN = "green" # Creativity & Innovation + BLUE = "blue" # Process & Meta-thinking + + +# Hat → BMAD items mapping +# Each hat evaluates specific BMAD items based on its perspective +HAT_TO_ITEMS: Dict[str, List[str]] = { + Hat.WHITE.value: ["A1", "A2", "A3", "A4", "C1", "D1", "D2"], + Hat.RED.value: ["A1", "A3", "B1", "C1", "C3"], + Hat.BLACK.value: ["B3", "B4", "C3", "C4", "C5"], + Hat.YELLOW.value: ["A3", "A4", "B1", "B2", "C5"], + Hat.GREEN.value: ["B1", "B2", "B3", "C1", "C2"], + Hat.BLUE.value: ["A1", "A2", "B1", "D1", "D2", "D3", "D4"], +} + +# Reverse mapping: BMAD item → hats that evaluate it +ITEM_TO_HATS: Dict[str, List[str]] = {} +for hat, items in HAT_TO_ITEMS.items(): + for item in items: + if item not in ITEM_TO_HATS: + ITEM_TO_HATS[item] = [] + ITEM_TO_HATS[item].append(hat) +# Sort for deterministic output +for item in ITEM_TO_HATS: + ITEM_TO_HATS[item] = sorted(ITEM_TO_HATS[item]) + + +def get_items_for_hat(hat: str) -> List[str]: + """Get BMAD items evaluated by a specific hat. + + Args: + hat: The hat color (white, red, black, yellow, green, blue). + + Returns: + Sorted list of BMAD item IDs evaluated by this hat. + """ + return sorted(HAT_TO_ITEMS.get(hat, [])) + + +def get_hats_for_item(item_id: str) -> List[str]: + """Get hats that evaluate a specific BMAD item. + + Args: + item_id: The BMAD item ID (e.g., "A1", "B2"). + + Returns: + Sorted list of hat colors that evaluate this item. + """ + return ITEM_TO_HATS.get(item_id, []) + + +def get_all_hats() -> List[str]: + """Get all hat values. + + Returns: + List of all six hat color values. + """ + return [h.value for h in Hat] + + +def validate_coverage() -> List[str]: + """Return list of BMAD items NOT covered by any hat (should be empty). + + Returns: + Sorted list of uncovered BMAD item IDs. Empty list means full coverage. + """ + from app.criteria.bmad_items import BMAD_ITEMS + + all_items = set(BMAD_ITEMS.keys()) + covered = set(ITEM_TO_HATS.keys()) + return sorted(all_items - covered) diff --git a/backend/app/criteria/technique_mappings.py b/backend/app/criteria/technique_mappings.py new file mode 100644 index 0000000..f82aefc --- /dev/null +++ b/backend/app/criteria/technique_mappings.py @@ -0,0 +1,191 @@ +"""Technique to Hat/Item/Mode mappings. + +Maps techniques to their primary BMAD evaluation items and provides +filtering by evaluation mode (grand_tasting, six_sommeliers, full_techniques). +""" + +from typing import Dict, List, Optional + +from app.techniques.mappings import TECHNIQUE_PRIORITY, Priority +from app.techniques.registry import get_registry + + +# Technique → BMAD item mappings (primary evaluations) +# Each technique has primary items it evaluates +TECHNIQUE_TO_ITEMS: Dict[str, List[str]] = { + # Aroma (problem-analysis) techniques + "five-whys": ["A1", "A2"], + "5w1h": ["A1", "A2", "A3"], + "question-storming": ["A1", "A3"], + "failure-analysis": ["A4", "B4"], + "assumption-reversal": ["A3", "A4"], + "data-mining": ["A2", "A3"], + "fact-checking": ["A1", "D1"], + "morphological-analysis": ["A3", "B2"], + "pestle-analysis": ["A3", "A4"], + "mind-mapping": ["A1", "B1"], + "constraint-mapping": ["A4", "B3"], + # Palate (innovation) techniques + "first-principles-thinking": ["B1", "B2"], + "scamper": ["B1", "B2"], + "design-thinking": ["B1", "A2"], + "triz": ["B2", "B3"], + "cross-pollination": ["B1", "B2"], + "concept-blending": ["B1", "B2"], + "lateral-thinking": ["B1", "B3"], + "random-stimulation": ["B1"], + "biomimicry": ["B2", "B3"], + "analogical-thinking": ["B1", "B2"], + "reversal-inversion": ["B1", "B3"], + "provocation-technique": ["B1"], + "quantum-superposition": ["B1", "B2"], + # Body (risk-analysis) techniques + "reverse-brainstorming": ["B4", "C3"], + "pre-mortem": ["B4", "C3"], + "swot-analysis": ["B3", "B4"], + "fmea": ["B4", "C3"], + "risk-matrix": ["B4", "C4"], + "anti-solution": ["B4", "C3"], + "devil-advocate": ["B4", "C3"], + "zombie-apocalypse": ["B4"], + # Finish (user-centricity) techniques + "empathy-mapping": ["A2", "A3"], + "jobs-to-be-done": ["A2", "A3"], + "kano-model": ["A2", "A4"], + "persona-journey": ["A2", "A3"], + "role-playing": ["A2"], + "emotional-journey": ["A2", "A3"], + "sensory-exploration": ["A2"], + "gut-check": ["A1"], + "body-wisdom-dialogue": ["A2"], + "inner-child-conference": ["A2"], + "alien-anthropologist": ["A2", "A3"], + "first-impression-analysis": ["A1", "D1"], + # Balance (feasibility) techniques + "technology-readiness-level": ["B2", "B3"], + "porters-five-forces": ["A4", "B3"], + "ecosystem-thinking": ["B3", "C5"], + "chaos-engineering": ["C3", "C4"], + "resource-constraints": ["B3", "C4"], + "evolutionary-pressure": ["B3"], + "trait-transfer": ["B2"], + "decision-tree-mapping": ["B3", "C4"], + # Vintage (opportunity) techniques + "scenario-planning": ["A4", "B3"], + "okr": ["A1", "A3"], + "opportunity-spotting": ["A3", "A4"], + "what-if-scenarios": ["A4", "B3"], + "value-mapping": ["A3", "A4"], + "strength-analysis": ["A3", "B1"], + "plus-points": ["A3"], + "yes-and-building": ["A3", "B1"], + "future-self-interview": ["A4"], + "permission-giving": ["A3"], + # Terroir (presentation) techniques + "metaphor-mapping": ["D1", "D3"], + "mythic-frameworks": ["D1", "D3"], + "emotion-orchestra": ["D1"], + "time-travel-talk-show": ["D1", "D4"], + "drunk-history-retelling": ["D1"], + # Cellar (synthesis) techniques + "business-model-canvas": ["A4", "B1"], + "balanced-scorecard": ["A3", "B1"], + "meta-analysis": ["C1", "C2"], + "six-thinking-hats": ["A1", "B1"], + "synthesis-framework": ["C1", "D3"], + "priority-matrix": ["B3", "C4"], + "consensus-building": ["D3", "D4"], + "indigenous-wisdom": ["A3"], +} + + +def get_techniques_for_hat(hat: str) -> List[str]: + """Get technique IDs that are applicable to a given hat. + + Args: + hat: The hat color (white, red, black, yellow, green, blue). + + Returns: + Sorted list of technique IDs applicable to this hat. + """ + registry = get_registry() + all_techs = registry.list_techniques() + result = [] + for tech in all_techs: + if hat in tech.applicable_hats: + result.append(tech.id) + return sorted(result) + + +def get_techniques_for_item(item_code: str) -> List[str]: + """Get technique IDs that evaluate a specific BMAD item. + + Args: + item_code: The BMAD item ID (e.g., "A1", "B2"). + + Returns: + Sorted list of technique IDs that evaluate this item. + """ + return sorted( + [tech_id for tech_id, items in TECHNIQUE_TO_ITEMS.items() if item_code in items] + ) + + +def get_techniques_for_mode(mode: str) -> List[str]: + """Get technique IDs filtered by evaluation mode and priority. + + Args: + mode: The evaluation mode ("full_techniques", "grand_tasting", "six_sommeliers"). + + Returns: + Sorted list of technique IDs matching the mode criteria. + """ + registry = get_registry() + all_techs = registry.list_techniques() + all_ids = [t.id for t in all_techs] + + if mode == "full_techniques": + return sorted(all_ids) + + if mode == "grand_tasting": + return sorted( + [ + t_id + for t_id in all_ids + if TECHNIQUE_PRIORITY.get(t_id, Priority.P2) == Priority.P0 + ] + ) + + if mode == "six_sommeliers": + return sorted( + [ + t_id + for t_id in all_ids + if TECHNIQUE_PRIORITY.get(t_id, Priority.P2) + in (Priority.P0, Priority.P1) + ] + ) + + return sorted(all_ids) + + +def get_primary_technique_for_item(item_code: str) -> Optional[str]: + """Get the highest priority technique for a BMAD item. + + Args: + item_code: The BMAD item ID (e.g., "A1", "B2"). + + Returns: + The highest priority technique ID, or None if no techniques evaluate this item. + """ + tech_ids = get_techniques_for_item(item_code) + if not tech_ids: + return None + best = None + best_priority = Priority.P2.value + 1 + for t_id in tech_ids: + p = TECHNIQUE_PRIORITY.get(t_id, Priority.P2).value + if p < best_priority: + best_priority = p + best = t_id + return best diff --git a/backend/app/graph/state.py b/backend/app/graph/state.py index 309d3c5..d017be7 100644 --- a/backend/app/graph/state.py +++ b/backend/app/graph/state.py @@ -6,6 +6,31 @@ from app.models.graph import TraceEvent, ItemScore, ExcludedTechnique, AgentContribution +def merge_hat_contributions( + current: Optional[Dict[str, object]], incoming: Optional[Dict[str, object]] +) -> Dict[str, object]: + """Merge hat contributions with deep merge of lists.""" + current = current or {} + incoming = incoming or {} + result = dict(current) + for hat, data in incoming.items(): + if hat not in result: + result[hat] = data + else: + existing = result[hat] + if isinstance(existing, dict) and isinstance(data, dict): + merged = dict(existing) + for k, v in data.items(): + if isinstance(v, list) and isinstance(merged.get(k), list): + merged[k] = sorted(set(merged[k]) | set(v)) + else: + merged[k] = v + result[hat] = merged + else: + result[hat] = data + return result + + def merge_dicts( current: Optional[Dict[str, object]], incoming: Optional[Dict[str, object]] ) -> Dict[str, object]: @@ -224,3 +249,18 @@ class EvaluationState(TypedDict): evaluated_count: NotRequired[int] unevaluated_count: NotRequired[int] coverage_rate: NotRequired[float] + + # Full techniques evaluation fields + evaluation_mode: NotRequired[str] + github_url: NotRequired[Optional[str]] + github_analysis: NotRequired[Optional[dict]] + user_api_key: NotRequired[Optional[str]] + api_key_source: NotRequired[Optional[str]] + hat_contributions: NotRequired[Annotated[dict, merge_hat_contributions]] + total_score: NotRequired[float] + quality_gate: NotRequired[str] + category_scores: NotRequired[dict[str, float]] + strengths: NotRequired[list[str]] + improvements: NotRequired[list[dict[str, str]]] + evaluated_items: NotRequired[list[str]] + excluded_items: NotRequired[list[str]] diff --git a/backend/app/models/graph.py b/backend/app/models/graph.py index b40c487..ab874f4 100644 --- a/backend/app/models/graph.py +++ b/backend/app/models/graph.py @@ -481,7 +481,7 @@ class ItemScore(BaseModel): """ item_id: str = Field(description="Unique identifier for the evaluated item") - score: float = Field(ge=0, le=100, description="Score value between 0 and 100") + score: float = Field(ge=0, description="Score value (0 or greater, no upper limit)") evaluated_by: str = Field( description="Name of the agent that performed the evaluation" ) @@ -493,6 +493,32 @@ class ItemScore(BaseModel): default=None, description="Optional notes or comments about the evaluation" ) + # Extended fields for detailed evaluation (backward compatible) + item_name: Optional[str] = Field( + default=None, description="Human-readable name of the item" + ) + max_score: Optional[float] = Field( + default=None, description="Maximum possible score for this item" + ) + status: Optional[str] = Field( + default=None, description="Evaluation status (e.g., 'evaluated', 'excluded')" + ) + unevaluated_reason: Optional[str] = Field( + default=None, description="Reason if item was not evaluated" + ) + hat_used: Optional[str] = Field( + default=None, description="Hat/agent type that performed the evaluation" + ) + evidence: Optional[list[str]] = Field( + default=None, description="List of evidence references" + ) + rationale: Optional[str] = Field( + default=None, description="Explanation for the score" + ) + confidence: Optional[str] = Field( + default=None, description="Confidence level in the evaluation" + ) + class ExcludedTechnique(BaseModel): """Technique that was excluded from evaluation. diff --git a/backend/tests/test_hat_mappings.py b/backend/tests/test_hat_mappings.py new file mode 100644 index 0000000..f63b573 --- /dev/null +++ b/backend/tests/test_hat_mappings.py @@ -0,0 +1,74 @@ +"""Tests for hat_mappings module.""" + +from app.criteria.bmad_items import BMAD_ITEMS +from app.criteria.hat_mappings import ( + HAT_TO_ITEMS, + ITEM_TO_HATS, + Hat, + get_all_hats, + get_hats_for_item, + get_items_for_hat, + validate_coverage, +) + + +class TestHatMappings: + """Test cases for hat to BMAD item mappings.""" + + def test_all_17_bmad_items_have_at_least_one_hat(self): + """Every item from BMAD_ITEMS has at least one hat.""" + for item_id in BMAD_ITEMS.keys(): + hats = get_hats_for_item(item_id) + assert len(hats) >= 1, f"BMAD item {item_id} has no hats" + + def test_validate_coverage_returns_empty(self): + """validate_coverage() returns [].""" + uncovered = validate_coverage() + assert uncovered == [], f"Uncovered BMAD items: {uncovered}" + + def test_known_hat_item_relationships(self): + """Known hat→item relationships exist.""" + assert "A1" in get_items_for_hat("white") + assert "B4" in get_items_for_hat("black") + assert "B1" in get_items_for_hat("green") + assert "A3" in get_items_for_hat("yellow") + assert "D1" in get_items_for_hat("blue") + assert "C1" in get_items_for_hat("red") + + def test_get_items_for_hat_returns_sorted(self): + """Results from get_items_for_hat are sorted.""" + items = get_items_for_hat("white") + assert items == sorted(items) + + def test_six_hats_defined(self): + """Six hats are defined in the Hat enum.""" + assert len(Hat) == 6 + + def test_get_all_hats(self): + """get_all_hats returns 6 hat values.""" + hats = get_all_hats() + assert len(hats) == 6 + assert set(hats) == {"white", "red", "black", "yellow", "green", "blue"} + + def test_reverse_mapping_consistency(self): + """If hat→item exists, then item→hat exists.""" + for hat, items in HAT_TO_ITEMS.items(): + for item in items: + assert hat in ITEM_TO_HATS[item], ( + f"{hat}→{item} exists but {item}→{hat} missing" + ) + + def test_all_hat_values_in_mapping(self): + """All hat enum values have entries in HAT_TO_ITEMS.""" + for hat in Hat: + assert hat.value in HAT_TO_ITEMS, f"Hat {hat.value} not in HAT_TO_ITEMS" + + def test_no_duplicate_items_per_hat(self): + """Each hat has unique items (no duplicates).""" + for hat, items in HAT_TO_ITEMS.items(): + assert len(items) == len(set(items)), f"Hat {hat} has duplicate items" + + def test_item_to_hats_sorted(self): + """ITEM_TO_HATS values are sorted.""" + for item, hats in ITEM_TO_HATS.items(): + assert hats == sorted(hats), f"Hats for {item} not sorted" diff --git a/backend/tests/test_item_score_model.py b/backend/tests/test_item_score_model.py new file mode 100644 index 0000000..f0b5aca --- /dev/null +++ b/backend/tests/test_item_score_model.py @@ -0,0 +1,104 @@ +import pytest +from pydantic import ValidationError +from app.models.graph import ItemScore + + +class TestItemScoreModel: + def test_old_style_item_score(self): + score = ItemScore( + item_id="test-item-1", + score=85.0, + evaluated_by="test-agent", + technique_id="tech-1", + timestamp="2026-02-09T10:00:00Z", + notes="Test notes", + ) + assert score.item_id == "test-item-1" + assert score.score == 85.0 + assert score.evaluated_by == "test-agent" + assert score.technique_id == "tech-1" + assert score.timestamp == "2026-02-09T10:00:00Z" + assert score.notes == "Test notes" + assert score.item_name is None + assert score.max_score is None + + def test_new_style_item_score_all_fields(self): + score = ItemScore( + item_id="test-item-2", + score=7.0, + evaluated_by="marcel", + technique_id="bmad-1", + timestamp="2026-02-09T10:00:00Z", + notes="Detailed evaluation", + item_name="Architecture Quality", + max_score=7.0, + status="evaluated", + unevaluated_reason=None, + hat_used="cellar_master", + evidence=["ref1", "ref2"], + rationale="Well structured codebase", + confidence="high", + ) + assert score.score == 7.0 + assert score.max_score == 7.0 + assert score.item_name == "Architecture Quality" + assert score.hat_used == "cellar_master" + assert score.evidence == ["ref1", "ref2"] + + def test_bmad_scale_score_valid(self): + score = ItemScore( + item_id="bmad-item", + score=7.0, + max_score=7.0, + evaluated_by="agent", + technique_id="bmad-tech", + timestamp="2026-02-09T10:00:00Z", + ) + assert score.score == 7.0 + assert score.max_score == 7.0 + + def test_score_below_zero_fails(self): + with pytest.raises(ValidationError) as exc_info: + ItemScore( + item_id="test-item", + score=-1.0, + evaluated_by="agent", + technique_id="tech", + timestamp="2026-02-09T10:00:00Z", + ) + assert "score" in str(exc_info.value) + + def test_score_at_zero_valid(self): + score = ItemScore( + item_id="test-item", + score=0.0, + evaluated_by="agent", + technique_id="tech", + timestamp="2026-02-09T10:00:00Z", + ) + assert score.score == 0.0 + + def test_score_above_100_valid(self): + score = ItemScore( + item_id="test-item", + score=150.0, + evaluated_by="agent", + technique_id="tech", + timestamp="2026-02-09T10:00:00Z", + ) + assert score.score == 150.0 + + def test_partial_new_fields(self): + score = ItemScore( + item_id="test-item", + score=5.0, + evaluated_by="agent", + technique_id="tech", + timestamp="2026-02-09T10:00:00Z", + item_name="Partial Test", + confidence="medium", + ) + assert score.item_name == "Partial Test" + assert score.confidence == "medium" + assert score.max_score is None + assert score.evidence is None diff --git a/backend/tests/test_quality_gate.py b/backend/tests/test_quality_gate.py new file mode 100644 index 0000000..b832e9c --- /dev/null +++ b/backend/tests/test_quality_gate.py @@ -0,0 +1,50 @@ +import pytest +from app.constants import ( + get_quality_gate, + PASS_THRESHOLD, + CONCERNS_THRESHOLD, + COVERAGE_THRESHOLD, +) + + +class TestQualityGate: + def test_pass_threshold_exact(self): + result = get_quality_gate(70.0, 0.5) + assert result == "PASS" + + def test_pass_threshold_high_coverage(self): + result = get_quality_gate(100.0, 1.0) + assert result == "PASS" + + def test_concerns_threshold_exact(self): + result = get_quality_gate(50.0, 0.5) + assert result == "CONCERNS" + + def test_concerns_between_thresholds(self): + result = get_quality_gate(69.9, 0.5) + assert result == "CONCERNS" + + def test_fail_below_concerns(self): + result = get_quality_gate(49.9, 0.5) + assert result == "FAIL" + + def test_fail_at_zero(self): + result = get_quality_gate(0.0, 1.0) + assert result == "FAIL" + + def test_incomplete_low_coverage(self): + result = get_quality_gate(85.0, 0.3) + assert result == "INCOMPLETE" + + def test_incomplete_boundary_low(self): + result = get_quality_gate(85.0, 0.49) + assert result == "INCOMPLETE" + + def test_pass_at_coverage_threshold(self): + result = get_quality_gate(85.0, 0.5) + assert result == "PASS" + + def test_constants_defined(self): + assert PASS_THRESHOLD == 70 + assert CONCERNS_THRESHOLD == 50 + assert COVERAGE_THRESHOLD == 0.5 diff --git a/backend/tests/test_technique_mappings.py b/backend/tests/test_technique_mappings.py index b31868d..db89c65 100644 --- a/backend/tests/test_technique_mappings.py +++ b/backend/tests/test_technique_mappings.py @@ -3,7 +3,6 @@ import pytest from app.techniques.mappings import ( - InvalidMappingError, Priority, TastingNote, get_category_summary, @@ -168,3 +167,104 @@ def test_p0_is_highest(self): def test_p0_value_is_0(self): assert Priority.P0.value == 0 + + +class TestCriteriaTechniqueMappings: + """Test cases for app.criteria.technique_mappings module.""" + + def test_full_techniques_returns_75(self): + """get_techniques_for_mode('full_techniques') returns 75 techniques.""" + from app.criteria.technique_mappings import get_techniques_for_mode + + techs = get_techniques_for_mode("full_techniques") + assert len(techs) == 75, f"Expected 75 techniques, got {len(techs)}" + + def test_six_sommeliers_returns_p0_p1(self): + """six_sommeliers returns fewer than 75, only P0+P1.""" + from app.criteria.technique_mappings import get_techniques_for_mode + + techs = get_techniques_for_mode("six_sommeliers") + assert len(techs) < 75 + # All should be P0 or P1 + for t_id in techs: + p = get_technique_priority(t_id) + assert p in (Priority.P0, Priority.P1), f"{t_id} is not P0 or P1" + + def test_grand_tasting_returns_p0_only(self): + """grand_tasting returns fewer than six_sommeliers, only P0.""" + from app.criteria.technique_mappings import get_techniques_for_mode + + grand_tasting = get_techniques_for_mode("grand_tasting") + six_sommeliers = get_techniques_for_mode("six_sommeliers") + assert len(grand_tasting) < len(six_sommeliers) + # All should be P0 + for t_id in grand_tasting: + p = get_technique_priority(t_id) + assert p == Priority.P0, f"{t_id} is not P0" + + def test_mode_count_ordering(self): + """grand_tasting < six_sommeliers < full_techniques(75).""" + from app.criteria.technique_mappings import get_techniques_for_mode + + grand = len(get_techniques_for_mode("grand_tasting")) + six = len(get_techniques_for_mode("six_sommeliers")) + full = len(get_techniques_for_mode("full_techniques")) + assert grand < six < full + assert full == 75 + + def test_five_representative_mappings(self): + """Verify specific technique→item relationships.""" + from app.criteria.technique_mappings import TECHNIQUE_TO_ITEMS + + assert "A1" in TECHNIQUE_TO_ITEMS["five-whys"] + assert "A1" in TECHNIQUE_TO_ITEMS["5w1h"] + assert "A2" in TECHNIQUE_TO_ITEMS["empathy-mapping"] + assert "B1" in TECHNIQUE_TO_ITEMS["scamper"] + assert "B4" in TECHNIQUE_TO_ITEMS["pre-mortem"] + + def test_get_primary_technique_for_item_returns_highest_priority(self): + """get_primary_technique_for_item returns highest priority technique.""" + from app.criteria.technique_mappings import ( + get_primary_technique_for_item, + get_techniques_for_item, + ) + + # A1 has multiple techniques, should return a P0 one + primary = get_primary_technique_for_item("A1") + assert primary is not None + p = get_technique_priority(primary) + # Should be the lowest value (highest priority) + all_a1_techs = get_techniques_for_item("A1") + min_priority = min(get_technique_priority(t).value for t in all_a1_techs) + assert p.value == min_priority + + def test_get_techniques_for_item_a1(self): + """A1 has multiple techniques.""" + from app.criteria.technique_mappings import get_techniques_for_item + + techs = get_techniques_for_item("A1") + assert len(techs) > 1 + # Should include five-whys, 5w1h, etc. + assert "five-whys" in techs + assert "5w1h" in techs + + def test_all_techniques_have_items(self): + """All techniques in TECHNIQUE_TO_ITEMS have at least one item.""" + from app.criteria.technique_mappings import TECHNIQUE_TO_ITEMS + + for tech_id, items in TECHNIQUE_TO_ITEMS.items(): + assert len(items) >= 1, f"Technique {tech_id} has no items" + + def test_get_techniques_for_item_returns_sorted(self): + """get_techniques_for_item returns sorted list.""" + from app.criteria.technique_mappings import get_techniques_for_item + + techs = get_techniques_for_item("B1") + assert techs == sorted(techs) + + def test_get_techniques_for_mode_invalid_returns_all(self): + """Invalid mode returns all techniques.""" + from app.criteria.technique_mappings import get_techniques_for_mode + + techs = get_techniques_for_mode("invalid_mode") + assert len(techs) == 75