{"_id":"@agentplatform/agentic-domain-methodology","name":"@agentplatform/agentic-domain-methodology","dist-tags":{"latest":"0.11.1"},"versions":{"0.11.1":{"name":"@agentplatform/agentic-domain-methodology","version":"0.11.1","description":"Agentic Platform methodology domain package","license":"UNLICENSED","type":"module","main":"./dist/index.js","types":"./dist/index.d.ts","scripts":{"build":"tsc -p tsconfig.json","clean":"rm -rf dist tsconfig.tsbuildinfo","typecheck":"tsc -p tsconfig.json --noEmit"},"dependencies":{"@agentplatform/agentic-capability-validation":"^0.3.0","better-sqlite3":"^12.11.1"},"devDependencies":{"@types/better-sqlite3":"^7.6.13"},"publishConfig":{"access":"public"},"gitHead":"3208ab11c20a8fc085dc9c05fc8aecf55ff5cf6e","_id":"@agentplatform/agentic-domain-methodology@0.11.1","_nodeVersion":"24.13.1","_npmVersion":"11.8.0","dist":{"integrity":"sha512-/W78f6yf74eB9EtC1vi9dR291vWatxSMdC6HqpBTms+YxDBjtFiH7awFsiXnyO8KQqCGt/ZpHs4SIyrHtDD0tA==","shasum":"8052e06f53dd249988b08340da5f53de1d938b7f","tarball":"https://registry.npmjs.org/@agentplatform/agentic-domain-methodology/-/agentic-domain-methodology-0.11.1.tgz","fileCount":90,"unpackedSize":775676,"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEYCIQCCvcsAjvna1ezPJjGcT7KK/GdWXwSTdifl4djlCtIdkQIhAPkO1F5+V/nagEG7aGXM0Y/QvQMnag7q9GRARbGF2dZd"}]},"_npmUser":{"name":"soddong","email":"gus9300@naver.com"},"directories":{},"maintainers":[{"name":"dabonee","email":"jdbc4497@gmail.com"},{"name":"soddong","email":"gus9300@naver.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/agentic-domain-methodology_0.11.1_1782699183527_0.6443572566348739"},"_hasShrinkwrap":false}},"time":{"created":"2026-06-29T02:13:02.783Z","0.11.1":"2026-06-29T02:13:03.681Z","modified":"2026-06-29T02:13:04.186Z"},"maintainers":[{"name":"dabonee","email":"jdbc4497@gmail.com"},{"name":"soddong","email":"gus9300@naver.com"}],"description":"Agentic Platform methodology domain package","license":"UNLICENSED","readme":"# agentic-domain-methodology\n\n`agentic-domain-methodology`는 Agentic Platform의 방법론 도메인 패키지입니다.\n\n이 패키지는 Methodology, Lifecycle, Phase, Process, Stage, Activity, Step, Gate, Handoff, Artifact Requirement, Common Blueprint Policy 같은 방법론 구조를 관리하기 위한 하위 도메인 패키지입니다.\n\n## 현재 범위\n\n현재는 패키지 skeleton, Continuous Publish/Delivery 기반, methodology SQLite schema migration, database helper, 핵심 Repository/Service API, Common Blueprint Policy, Activity Artifact Requirement의 artifact component 참조, Stage Criteria API, Handoff Requirement API, Build Planning fixture/seed, runtime seed apply handler, 최소 validator, scoped validation을 제공합니다. Agent contribution은 후속 iteration에서 구체화합니다.\n\n| 구분 | 상태 |\n| --- | --- |\n| 패키지 skeleton | 포함 |\n| 기본 문서 | 포함 |\n| build/typecheck | 포함 |\n| pack dry-run | 포함 |\n| 최소 public API | 포함 |\n| Methodology DB migration | 포함 |\n| Methodology database helper | 포함 |\n| Repository/Service | 핵심 생성/조회 API 포함 |\n| Common Blueprint Policy | 공통 Front/Back Matter 정책 포함 |\n| Activity Artifact Component Reference | Activity 산출물 요구가 artifact-standard의 특정 document component를 참조 가능 |\n| Stage Criteria API | Stage entry/exit/gate 기준 생성/조회 가능 |\n| Handoff Requirement API | 수행 단위 간 전달 계약 생성/조회 가능 |\n| Runtime Seed Apply Handler | AI-Agent SDLC seed의 methodology section 적용 가능 |\n| Validator | 최소 구조 정합성 검증 포함 |\n| Fixture/Seed | Build Planning 예시 포함 |\n| Agent contribution | 후속 iteration |\n| CLI | 1차 구현 제외 |\n| Adapter | 1차 구현 제외 |\n\n## 도메인 책임\n\n```text\nagentic-domain-methodology\n  - Methodology\n  - Lifecycle\n  - Phase\n  - Process\n  - Stage\n  - Activity\n  - Step\n  - Gate\n  - Entry/Exit Criteria\n  - Handoff\n  - Baseline\n  - Artifact Requirement\n  - Common Blueprint Policy\n  - Trace Policy\n```\n\n## Activity Artifact Requirement와 Document Component 참조\n\n`methodology`는 산출물 표준 내부 구조를 직접 소유하지 않습니다. 본문, 부록, 하위 부록 같은 산출물 구성 단위는 `agentic-domain-artifact-standard`의 `DocumentComponent`가 정의합니다.\n\n다만 Activity가 산출물 전체가 아니라 특정 구성 단위를 작성, 검토, 정제, 종합하는 경우가 있으므로 Activity Artifact Requirement는 optional component 참조를 가질 수 있습니다.\n\n```ts\nservice.addActivityArtifactRequirement({\n  activityId: activity.activityId,\n  artifactStandardCode: \"business_process_definition\",\n  artifactStandardVersion: \"1.0.0\",\n  artifactComponentCode: \"appendix_l3_process\",\n  artifactComponentRoleCode: \"APPENDIX\",\n  requirementRoleCode: \"output\",\n  outputUsageCode: \"produces\",\n  isPrimary: true\n});\n```\n\n의미는 다음과 같습니다.\n\n```text\nActivity: L3 프로세스 부록 작성\n  output artifact standard: business_process_definition@1.0.0\n  output component: appendix_l3_process\n  usage: produces\n```\n\n이 구조에서 `methodology`는 \"언제, 어떤 Activity가 어떤 산출물/component를 다루는가\"만 정의합니다. 산출물 내부 component 구조와 물리 파일 정책은 `artifact-standard`, 실제 산출물 instance 연결은 후속 `artifact` 책임입니다.\n\n하나의 Stage에서 여러 산출물 구성 요소를 작성하는 경우에는 component별 Activity output으로 분리할 수 있습니다.\n\n```text\nPlanning Phase\n  Business Architecture Planning Process\n    Stage: component_business_process_definition\n      Activity: business_process_main_document_authoring\n        output: business_process_definition@1.0.0 / main_document\n      Activity: l3_process_appendix_authoring\n        output: business_process_definition@1.0.0 / appendix_l3_process\n      Activity: scenario_appendix_authoring\n        output: business_process_definition@1.0.0 / appendix_scenario\n      Activity: l4_detail_appendix_authoring\n        output: business_process_definition@1.0.0 / appendix_l4_detail\n      Activity: business_process_definition_consolidation\n        input: main_document, appendix_l3_process, appendix_scenario, appendix_l4_detail\n        output: business_process_definition@1.0.0 / main_document\n        usage: refines\n```\n\n종합/정제처럼 여러 component를 읽고 MAIN 문서를 정제하는 작업도 Activity로 둘 수 있습니다. Stage gate/criterion은 이 Activity가 완료됐는지 판단하는 기준이고, handoff는 다음 Stage나 Process로 넘기는 관계입니다.\n\n한 산출물 구성 요소를 작성하는 내부 절차는 Step으로 표현할 수 있지만, 현재 조립 검증에서는 Step까지 세분화하지 않습니다.\n\n## Stage Criteria API\n\nStage의 시작, 종료, 전환 판단 기준은 `methodology_stage_criteria`와 Service API로 관리합니다.\n\n```ts\nconst exitCriteria = service.createStageCriteria({\n  stageId: stage.stageId,\n  criteriaTypeCode: \"exit\",\n  criteriaName: \"필수 component 생성\",\n  criteriaText: \"MAIN, L3 부록, 시나리오 부록, L4 상세 부록 component가 모두 생성되어야 한다.\",\n  validationRequired: true,\n  severityCode: \"error\",\n  sortOrder: 20,\n  metadata: {\n    criteriaCode: \"exit_required_components_created\"\n  }\n});\n\nconst criteria = service.listStageCriteriaByStage(stage.stageId);\nconsole.log(criteria.map((item) => item.criteriaTypeCode));\n```\n\n구분 기준은 다음과 같습니다.\n\n| criteriaTypeCode | 의미 |\n| --- | --- |\n| `entry` | Stage 시작 전 준비 조건 |\n| `exit` | Stage 종료를 위한 산출물/구조 완성 조건 |\n| `gate` | 다음 Stage 또는 승인 전환 판단 조건 |\n\n## Handoff Requirement API\n\nHandoff는 실제 파일을 복사하거나 이동하는 기능이 아니라, 후속 Phase/Process/Stage/Activity가 입력으로 받아야 하는 산출물, 이슈, 결정, 제약 조건 등의 전달 계약입니다.\n\n다수의 선행 산출물 component를 하나의 artifact instance 묶음으로 후행 Stage에 넘기는 경우에는 Handoff 1건에 필수 component 목록을 metadata로 둡니다.\n\n```ts\nconst handoff = service.createHandoffRequirement({\n  sourceScopeCode: \"stage\",\n  sourceRefId: businessProcessStage.stageId,\n  targetScopeCode: \"stage\",\n  targetRefId: informationObjectStage.stageId,\n  handoffTypeCode: \"artifact\",\n  handoffItemName: \"A컴포넌트 비즈니스 프로세스 정의서\",\n  handoffDescription: \"컴포넌트 정보 객체 정의 Stage에서 참조할 비즈니스 프로세스 정의서 산출물 묶음이다.\",\n  artifactStandardCode: \"business_process_definition\",\n  artifactStandardVersion: \"1.0.0\",\n  validationRequired: true,\n  sortOrder: 10,\n  metadata: {\n    handoffItemScope: \"artifact_instance\",\n    requiredComponentCodes: [\n      \"main_document\",\n      \"appendix_l3_process\",\n      \"appendix_scenario\",\n      \"appendix_l4_detail\"\n    ],\n    requiredResultRefs: [\n      \"validation_result\",\n      \"review_decision\"\n    ]\n  }\n});\n```\n\n후행 산출물을 LLM이 작성하는 경우 application 또는 runtime 조립 계층은 다음 순서로 context를 구성합니다.\n\n```text\n1. 후행 Activity 또는 Stage 식별\n2. target 기준 Handoff Requirement 조회\n3. handoff metadata의 required component set 확인\n4. artifact instance와 component resource link 조회\n5. ADoc document 내용 조회\n6. 후행 산출물의 artifact-standard 조회\n7. 선행 산출물 context + 후행 산출물 표준을 LLM prompt/resource context로 조립\n```\n\n조회 예:\n\n```ts\nconst inboundHandoffs = service.listHandoffRequirementsByTarget(\n  \"stage\",\n  informationObjectStage.stageId\n);\n\nconst outboundHandoffs = service.listHandoffRequirementsBySource(\n  \"stage\",\n  businessProcessStage.stageId\n);\n```\n\n## 제외 범위\n\n| 제외 항목 | 담당 후보 |\n| --- | --- |\n| Document 내부 구조 | `agentic-domain-document` |\n| Artifact Standard 본문 구조 | `agentic-domain-artifact-standard` |\n| Artifact instance | `agentic-domain-artifact` |\n| AI-Agent SDLC seed | `agentic-methodology-ai-agent-sdlc` |\n| Runner | `agentic-runtime` 또는 application package |\n| Render | render capability |\n| Adapter | `agentic-runtime` |\n\n## 명명 기준\n\n| 구분 | 기준 |\n| --- | --- |\n| logical schema | `methodology` |\n| SQLite table prefix | `methodology_` |\n| PostgreSQL mapping | 향후 중앙 DB 활용 시 `methodology.*` 후보 |\n\n## 개발 검증\n\n```bash\nnpm run build --workspace agentic-domain-methodology\nnpm run typecheck --workspace agentic-domain-methodology\nnpm run dev:test:agentic-domain-methodology\nnpm pack --workspace agentic-domain-methodology --dry-run --cache /private/tmp/agentic-npm-cache\n```\n\n## 기본 API 예시\n\n```ts\nimport {\n  applyAgenticSeed,\n  getMethodologyPackageInfo,\n  initializeMethodologyDatabase,\n  openMethodologyDatabase,\n  MethodologyService,\n  seedBuildPlanningExample,\n  validateMethodologyDefinition\n} from \"agentic-domain-methodology\";\n\nconsole.log(getMethodologyPackageInfo());\n\nconst result = initializeMethodologyDatabase({\n  projectRoot: process.cwd()\n});\n\nconsole.log(result.tables);\n\nconst db = openMethodologyDatabase({ projectRoot: process.cwd() });\nconst service = new MethodologyService(db);\n\nconst scenario = service.createDefinitionScenario({\n  methodology: {\n    methodologyCode: \"sdlc_default\",\n    methodologyName: \"기본 SDLC 방법론\",\n    methodologyVersion: \"1.0.0\"\n  },\n  lifecycle: {\n    lifecycleCode: \"default_lifecycle\",\n    lifecycleName: \"기본 Lifecycle\"\n  },\n  phase: {\n    phaseCode: \"analysis\",\n    phaseName: \"분석\"\n  },\n  process: {\n    processCode: \"requirements_management\",\n    processName: \"요구사항 관리\"\n  },\n  activity: {\n    activityCode: \"requirements_definition\",\n    activityName: \"요구사항 정의\"\n  }\n});\n\nconsole.log(scenario.activity.activityId);\n\nconst validation = validateMethodologyDefinition(db);\nconsole.log(validation.valid);\ndb.close();\n```\n\n## Process 추가 API 사용 기준\n\nProcess는 특정 Lifecycle에 직접 종속되는 데이터가 아니라 Methodology에 종속됩니다. Phase와 Process의 관계는 `methodology_phase_processes` 연결 테이블로 표현합니다.\n\n따라서 이미 생성된 Lifecycle 또는 Phase를 기준으로 Process를 추가할 때는 `createProcess()`에 `lifecycleId`를 넘기지 않습니다.\n\n잘못된 예:\n\n```ts\nservice.createProcess({\n  lifecycleId: scenario.lifecycle.lifecycleId,\n  processCode: \"architecture_design\",\n  processName: \"아키텍처 설계\"\n});\n```\n\n`createProcess()`는 `methodologyId`를 직접 받는 저수준 API입니다.\n\n```ts\nservice.createProcess({\n  methodologyId: scenario.methodology.methodologyId,\n  processCode: \"architecture_design\",\n  processName: \"아키텍처 설계\"\n});\n```\n\nconsumer 코드에서 Lifecycle 기준으로 Process를 추가하고 싶다면 `createProcessForLifecycle()`을 사용합니다.\n\n```ts\nconst process = service.createProcessForLifecycle({\n  lifecycleId: scenario.lifecycle.lifecycleId,\n  processCode: \"architecture_design\",\n  processName: \"아키텍처 설계\"\n});\n```\n\nPhase 기준으로 Process를 만들고 Phase에 바로 배정하려면 `createProcessForPhase()`를 사용합니다.\n\n```ts\nconst result = service.createProcessForPhase({\n  phaseId: scenario.phase.phaseId,\n  processCode: \"architecture_design\",\n  processName: \"아키텍처 설계\",\n  phaseProcess: {\n    sortOrder: 20\n  }\n});\n\nconsole.log(result.process.processId);\nconsole.log(result.phaseProcess.phaseProcessId);\n```\n\n## 조회/탐색 API 예시\n\n생성된 방법론 구조를 확인할 때는 직접 SQL을 작성하기보다 Service 조회 API를 우선 사용합니다.\n\n단위 목록 조회:\n\n```ts\nconst lifecycles = service.listLifecyclesByMethodology(scenario.methodology.methodologyId);\nconst phases = service.listPhasesByLifecycle(scenario.lifecycle.lifecycleId);\nconst processes = service.listProcessesByPhase(scenario.phase.phaseId);\nconst activities = service.listActivitiesByProcess(scenario.process.processId);\nconst stages = service.listStagesByProcess(scenario.process.processId);\nconst steps = service.listStepsByActivity(scenario.activity.activityId);\nconst outputs = service.listActivityArtifactRequirements(scenario.activity.activityId);\n```\n\n전체 구조 조회:\n\n```ts\nconst structure = service.getMethodologyStructure(scenario.methodology.methodologyId);\n\nfor (const lifecycle of structure.lifecycles) {\n  for (const phase of lifecycle.phases) {\n    for (const process of phase.processes) {\n      console.log(process.process.processName);\n      console.log(process.activities.map((item) => item.activity.activityName));\n      console.log(process.stages.map((item) => item.stage.stageName));\n    }\n  }\n}\n```\n\n`getMethodologyStructure()`는 Methodology -> Lifecycle -> Phase -> Process -> Activity/Stage 구조를 읽기 위한 편의 read model입니다. Stage 하위 Activity는 `methodology_stage_activities` 연결 기준으로 조회됩니다.\n\n## Fixture/Seed 사용 예시\n\n`seedBuildPlanningExample()`은 `temp/` 아래 Build Planning 방법론 정리 내용을 기준으로 구성한 예시 데이터를 생성합니다.\n\n포함 범위:\n\n- `Build Planning Phase`\n- `Build Planning Process`\n- `Analysis Stage`\n- `Interface Design Stage`\n- `Structure Design Stage`\n- `Build Scope Planning Stage`\n- Stage별 대표 Activity, Step, primary output artifact requirement\n- 특정 Stage에 종속되지 않는 Cross-cutting Governance Activity\n\n사용 예:\n\n```ts\nconst seedResult = seedBuildPlanningExample(db);\n\nconsole.log(seedResult.seeded);\nconsole.log(seedResult.structure.methodology.methodologyName);\nconsole.log(seedResult.structure.lifecycles[0].phases[0].processes[0].stages.length);\nconsole.log(seedResult.structure.lifecycles[0].phases[0].processes[0].activities.length);\n```\n\n동일한 `methodologyCode + methodologyVersion`이 이미 존재하면 중복 생성하지 않고 기존 구조를 반환합니다.\n\n```ts\nconst first = seedBuildPlanningExample(db);\nconst second = seedBuildPlanningExample(db);\n\nconsole.log(first.seeded);  // true\nconsole.log(second.seeded); // false\n```\n\n## Runtime Seed Apply Handler\n\n`applyAgenticSeed()`는 `agentic-runtime seed apply`가 target package를 호출할 때 사용하는 handler입니다.\n\n이 handler는 methodology 도메인이 소유하는 section만 처리합니다.\n\n| sourceSection | 처리 |\n| --- | --- |\n| `methodology` | Methodology 생성 또는 기존 항목 skip |\n| `lifecycle` | Lifecycle 생성 또는 기존 항목 skip |\n| `phases` | Phase 목록 생성 |\n| `processes` | Process 생성 및 Phase 연결 |\n| `stages` | Stage 목록 생성 |\n| `activities` | Activity 생성 및 Stage 연결 |\n| `activityArtifactRequirements` | Activity output/input/supporting artifact requirement 생성 |\n| `criteria` | Stage criteria 생성 |\n| `handoffs` | Stage 간 handoff requirement 생성 |\n\n`generatedOutputLinks`, `validationProfiles`, `sampleExecution`은 각각 `artifact-standard`, `validation`, `artifact` 계열 패키지의 책임입니다.\n\n예시:\n\n```ts\nawait applyAgenticSeed({\n  sourcePackageName: \"agentic-methodology-ai-agent-sdlc\",\n  sourcePackageVersion: \"0.2.0\",\n  bundleCode: \"ai-agent-sdlc-build-planning\",\n  bundleVersion: \"0.2.0\",\n  methodologyCode: \"ai_agent_sdlc\",\n  sourceSection: \"stages\",\n  targetOperation: \"upsert_stages\",\n  mode: \"apply\",\n  itemPayload: [\n    {\n      processCode: \"build_planning_process\",\n      stageCode: \"analysis_stage\",\n      stageName: \"Analysis Stage\",\n      stageTypeCode: \"analysis\",\n      stageOrder: 10\n    }\n  ]\n});\n```\n\n적용 결과는 다음 중 하나를 반환합니다.\n\n| status | 의미 |\n| --- | --- |\n| `applied` | 신규 methodology 데이터가 생성됨 |\n| `skipped` | 동일 기준의 데이터가 이미 있어 중복 생성하지 않음 |\n| `blocked` | 선행 methodology, lifecycle, phase, process, stage, activity 등이 없어 적용할 수 없음 |\n| `failed` | payload 필수값 누락 또는 DB 제약 오류 |\n\nAI-Agent SDLC seed의 `handoffTypeCode: \"stage_gate\"`는 현재 methodology DB의 공통 handoff type에 직접 포함되지 않으므로 `context`로 저장합니다. 원본 `stage_gate` 값은 metadata의 `seedPayload`에 보존합니다.\n\n## Validation Scope 사용 예시\n\n`validateMethodologyDefinition(db)`는 기본적으로 methodology DB 전체를 검증합니다. 하나의 consumer 프로젝트 안에 여러 방법론, 테스트 데이터, 의도적으로 만든 오류 데이터가 함께 있을 수 있으므로 특정 방법론만 검증해야 할 때는 scope를 지정합니다.\n\n방법론 ID 기준:\n\n```ts\nconst result = validateMethodologyDefinition(db, {\n  scope: {\n    methodologyId: seedResult.methodologyId\n  }\n});\n\nconsole.log(result.valid);\n```\n\n방법론 코드와 버전 기준:\n\n```ts\nconst result = validateMethodologyDefinition(db, {\n  scope: {\n    methodologyCode: \"build_planning_example\",\n    methodologyVersion: \"1.0.0\"\n  }\n});\n\nconsole.log(result.valid);\n```\n\n전체 validation은 DB 안의 모든 방법론과 테스트 데이터를 함께 검증합니다. 특정 fixture나 특정 방법론의 품질만 확인하려면 scoped validation을 사용합니다.\n\n기대 결과:\n\n```json\n{\n  \"name\": \"agentic-domain-methodology\",\n  \"version\": \"0.11.1\",\n  \"layer\": \"domain\",\n  \"logicalSchema\": \"methodology\",\n  \"sqliteTablePrefix\": \"methodology_\",\n  \"cli\": \"not-provided\",\n  \"adapter\": \"not-provided\"\n}\n```\n","readmeFilename":"README.md","_rev":"1-775a8cae635ce0860a67959c5c606247"}