@neobiotechlabs/neobiotech-dev-agent 0.1.16 → 0.1.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@neobiotechlabs/neobiotech-dev-agent",
-  "version": "0.1.16",
+  "version": "0.1.18",
   "description": "Jira & Confluence MCP Server for Claude Code",
   "type": "module",
   "main": "dist/index.js",
@@ -8,7 +8,7 @@
     "neobiotech-dev-agent": "dist/index.js"
   },
   "scripts": {
-    "build": "tsc --noEmit && tsup && node scripts/copy-pdfkit-data.mjs",
+    "build": "tsc --noEmit && tsup && node scripts/copy-pdfkit-data.mjs && node scripts/copy-fonts.mjs",
     "dev": "tsup --watch",
     "start": "node dist/index.js",
     "test": "vitest run",

package/vendor/dev-docs-templates/templates/mdr_docs/PA/configuration-management-plan.md

@@ -0,0 +1,112 @@
+# Configuration Management Plan
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 §8 (Configuration Management Process) 기반 형상관리 계획서입니다.
+PA 단계에서 작성하는 핵심 산출물로, 본 문서가 형상관리의 단일 진실의 원천입니다.
+SDMP(Software Development and Maintenance Plan)는 본 문서를 참조합니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 소프트웨어 개발 및 유지보수 계획서(software-development-maintenance-plan.md): 개발 워크플로우, 도구 체인
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 타겟 환경, 구성 항목 후보
+  - SOP Change Management (회사 QMS 자산; 시드 템플릿 global/qms/sop-change-management.md):
+    회사 수준의 변경 평가·통제 절차. CMP는 본 기기의 형상관리를, SOP는 회사 전체의
+    변경 통제 절차를 다룬다(상호 보완). 첫 기기 개발 시 회사 QMS asset이 아직 없으면
+    상기 시드 템플릿으로 자사 SOP를 먼저 작성할 것.
+
+작성 지침:
+1. Section 2 (형상 식별): 형상 항목(CI) 후보를 식별하세요 — 소스 코드, 빌드 스크립트, SOUP, 문서, 환경 설정
+2. Section 3 (버전 통제): 버전 네이밍 체계(시맨틱 버저닝)와 태그 정책을 정의하세요
+3. Section 4 (변경 통제): Change Evaluation List 연계 절차를 기술하세요
+4. Section 5 (형상 감사): 감사 주기·기준을 정의하세요
+5. 본 문서는 PA 'Plan' 성격 — 구현 세부(도구 세부 설정 등)는 EA/운영 단계로 미룸
+
+완성 체크리스트:
+  [ ] 형상 항목(CI) 식별 기준 명시
+  [ ] 버전 넘버링·태그 정책 정의
+  [ ] 변경 통제 절차(SOP Change Management 연계) 기술
+  [ ] 형상 감사 일정·기준 정의
+  [ ] 형상 관리 담당자(Configuration Manager) 지정
+-->
+
+{PROJECT_NAME}의 소프트웨어 형상관리 계획서. 본 문서는 IEC 62304 §8에 따라 형상관리 프로세스를
+정의하며, 모든 형상 관리 활동의 단일 진실의 원천이다. 작성자: {AUTHOR}, 티켓: {TICKET_ID}, 일자: {DATE}.
+
+## Mapping of Standard Requirements to Document Sections
+
+| Standard                | Clause                                                              | Document Section |
+| ----------------------- | ------------------------------------------------------------------- | ---------------- |
+| IEC 62304               | 5.1.9 Software Configuration Management Planning                    | 3                |
+| IEC 62304               | 5.1.10 Supporting Items to be Controlled                            | 2                |
+| IEC 62304               | 5.1.11 Software Configuration Item Control Before Verification      | 7                |
+| IEC 62304               | 8.1 Configuration Identification                                    | 2                |
+| IEC 62304               | 8.2 Change Control                                                  | 4                |
+| IEC 62304               | 8.3 Configuration Status Accounting                                 | 5                |
+| IEC 62304               | 8.4 Configuration Audit                                             | 6                |
+| ISO 13485:2016          | 7.3.7 Design and Development Verification (configuration aspects)  | 6, 7             |
+| ISO 13485:2016          | 7.5 Document Control (applied to configuration items)               | 3                |
+
+## 1. Purpose and Scope
+
+> 이 계획서의 목적과 적용 범위를 기술하세요. 어떤 소프트웨어 제품/버전에 적용되는지 명시.
+
+{SCOPE_DESCRIPTION}
+
+## 2. Configuration Identification
+
+> 형상 항목(Configuration Item, CI)을 식별하는 기준을 정의하세요. 각 CI는 고유 식별자·버전을 갖는다.
+
+형상 항목 후보:
+* 소스 코드 (레포지토리 단위)
+* 빌드 스크립트 및 환경 설정 (CI/CD 파이프라인 정의 포함)
+* SOUP (third-party 의존성, lockfile)
+* 소프트웨어 문서 (요구사항·설계·테스트 산출물)
+* 빌드 산출물 (release artifact)
+
+| CI Category    | Naming Convention | Tool           |
+| -------------- | ----------------- | -------------- |
+| {CI_CATEGORY}  | {CI_NAMING}       | {CI_TOOL}      |
+
+## 3. Version Control
+
+> 버전 네이밍 체계와 태그 정책을 정의하세요. 시맨틱 버저닝(MAJOR.MINOR.PATCH) 권장.
+
+* 버전 체계: {VERSION_SCHEME} (예: Semantic Versioning 2.0.0)
+* 태그 정책: {TAG_POLICY} (각 release 커밋에 tag 부여, 과거 버전 복원 가능해야 함)
+* 버전 관리 도구: Git
+
+## 4. Change Control
+
+> 변경 통제 절차를 기술하세요. SOP Change Management와 연계.
+
+변경 요청 → 영향 평가(Change Evaluation List) → 승인 → 구현 → 검증의 흐름을 따른다.
+자세한 절차는 SOP Change Management를 참조한다. 본 절에서는 소프트웨어 형상 항목에
+특화된 통제 기준만 명시한다.
+
+* 변경 요청 기록: {CHANGE_REQUEST_LOCATION}
+* 승인 권한자: {CHANGE_APPROVER}
+
+## 5. Configuration Status Accounting
+
+> 형상 상태 기록(status accounting) — 현재 각 CI의 버전·상태를 추적·보고하는 방법.
+
+{STATUS_ACCOUNTING_METHOD}
+
+## 6. Configuration Audit
+
+> 형상 감사 일정·기준. 기능/물리 형상 감사(Functional/Physical Configuration Audit).
+
+* 감사 주기: {AUDIT_FREQUENCY}
+* 감사 기준: {AUDIT_CRITERIA}
+
+## 7. Configuration Item Control Before Verification
+
+> 검증 활동 시작 전, 검증 대상 형상 항목이 통제되어야 함. 검증 대상 CI 식별·고정 방법.
+
+{PRE_VERIFICATION_CONTROL}
+
+## 8. Roles
+
+| Title                 | Name(s) |
+| --------------------- | ------- |
+| Configuration Manager |         |
+| Release Manager       |         |

package/vendor/dev-docs-templates/templates/mdr_docs/PA/security-management-plan.md

@@ -0,0 +1,101 @@
+# Security Management Plan
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 81001-5-1:2021 (Health software — Part 5-1: Security activities
+in the software lifecycle) 및 AAMI TIR57 기반 보안 관리 계획서입니다.
+PA 단계 핵심 산출물로, 본 문서가 보안의 단일 진실의 원천입니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 소프트웨어 개발 및 유지보수 계획서(software-development-maintenance-plan.md): 개발 프로세스
+  - 위험 관리 계획서(risk-management-plan.md): 위해 정의, 위험 수용 기준
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 시스템 경계, 자산
+
+작성 지침:
+1. Section 1 (보안 정책): Security by Design 원칙과 조직 보안 정책을 명시
+2. Section 3 (위협 모델링): 접근법(STRIDE 등)만 명시 — 구체적 위협 목록은 EA 산출물
+3. Section 5 (보안 V&V): 어떤 검증을 수행할지(SAST/SCA/침투테스트)만 명시 — 도구·절차 세부는 EA
+4. 본 문서는 PA 'Plan' 성격 — 구현 세부(SBOM 도구명·CVD runbook 등)는 EA/운영 단계로 미룸
+
+완성 체크리스트:
+  [ ] 보안 정책(Security by Design) 명시
+  [ ] 자산·위협 모델링 접근법 정의
+  [ ] 보안 요구사항 도출 기준(CIA) 정의
+  [ ] 보안 V&V 접근법(SAST/SCA/펜테스트) 명시
+  [ ] 취약점 관리·CVE 모니터링 주기 정의
+  [ ] 보안 담당자(Security Manager) 지정
+-->
+
+{PROJECT_NAME}의 보안 관리 계획서. 본 문서는 IEC 81001-5-1:2021에 따라 소프트웨어 보안
+활동을 정의하며, 보안의 단일 진실의 원천이다. 작성자: {AUTHOR}, 티켓: {TICKET_ID}, 일자: {DATE}.
+
+## Mapping of Standard Requirements to Document Sections
+
+| Standard                | Clause                                                                          | Document Section |
+| ----------------------- | ------------------------------------------------------------------------------- | ---------------- |
+| IEC 81001-5-1:2021      | 5.1.1 Cybersecurity risk management plan                                        | all              |
+| IEC 81001-5-1:2021      | 5.2 Threat modelling                                                            | 3                |
+| IEC 81001-5-1:2021      | 5.3 Specification of security requirements                                       | 4                |
+| IEC 81001-5-1:2021      | 5.4 Implementation of security controls (planning)                              | 4                |
+| IEC 81001-5-1:2021      | 5.5 Cybersecurity risk control verification (approach)                          | 5                |
+| IEC 81001-5-1:2021      | 7 Cybersecurity activities in the operation phase (approach)                    | 6, 7             |
+| AAMI TIR57              | Security Risk Management Process                                                | 3, 4             |
+
+## 1. Purpose, Scope and Security Policy
+
+> 목적·적용 범위·Security by Design 원칙·조직 보안 정책을 기술.
+
+* Security by Design 원칙: 최소 권한, 방어 심도, 보안 기본값(deny-by-default)
+* {SECURITY_POLICY}
+
+## 2. Security Organization and Roles
+
+| Title             | Name(s) |
+| ----------------- | ------- |
+| Security Manager  |         |
+| Incident Response |         |
+
+## 3. Threat Modelling Approach
+
+> 위협 모델링 **접근법**만 명시. 구체적 위협 식별·평가는 EA 산출물로 이관.
+
+* 방법론: {THREAT_METHODOLOGY} (예: STRIDE — Spoofing/Tampering/Repudiation/Info Disclosure/DoS/Elevation of Privilege)
+* 자산 식별 범위: {ASSET_SCOPE}
+
+## 4. Security Requirements
+
+> 보안 요구사항 도출 기준. CIA(기밀성·무결성·가용성) 관점.
+
+도출 기준:
+* 인증(Authentication): {AUTH_CRITERIA}
+* 권한 부여(Authorization): {AUTHZ_CRITERIA}
+* 암호화(Encryption): {CRYPTO_CRITERIA}
+* 로깅·감사(Logging): {LOGGING_CRITERIA}
+
+## 5. Security V&V Approach
+
+> 보안 검증 **접근법** — 무엇을 수행할지만 명시. 도구·절차 세부는 EA.
+
+* 정적 분석(SAST): {SAST_APPROACH}
+* 소프트웨어 구성 분석(SCA) / 취약점 스캔: {SCA_APPROACH}
+* 침투 테스트: {PENTEST_APPROACH}
+
+## 6. Vulnerability Management
+
+> 취약점 관리·CVE 모니터링 주기 — 계획 수준.
+
+* CVE 모니터링 주기: {CVE_MONITORING_FREQUENCY}
+* 취약점 등록·조치: {VULN_TRACKING}
+
+## 7. Cybersecurity Incident Response / CVD
+
+> 보안 사고 대응·Coordinated Vulnerability Disclosure 접근법 — 계획 수준.
+
+* 사고 대응 절차: {INCIDENT_RESPONSE}
+* CVD 정책: {CVD_POLICY}
+
+## 8. SBOM Management
+
+> Software Bill of Materials 관리 방침.
+
+* SBOM 형식: {SBOM_FORMAT} (예: SPDX, CycloneDX)
+* 생성·갱신 시점: {SBOM_GENERATION}

package/vendor/dev-docs-templates/templates/mdr_docs/PA/software-development-maintenance-plan.md

@@ -14,21 +14,17 @@
    - EA: 요구사항 및 설계 -> 코딩 시작 전 승인
    - ER: 구현 및 검증 -> Sprint 반복 (Sprint No, 완료 일자 기입)
    - CA: 최종 릴리스 -> 검증 완료 후 승인
-3. Section 5 (Configuration Management): 반드시 상세히 작성하세요 (형상관리 계획 역할)
-   - Git 브랜치 전략 (feature/release/main 등)
-   - 버전 체계 (semantic versioning: MAJOR.MINOR.PATCH)
-   - 변경 통제 절차 (Change Evaluation List 참조)
-4. 사이버보안 계획은 별도 파일 없이 이 SDP 내에 챕터로 작성하세요:
-   - 보안 설계 원칙 (Security by Design)
-   - 취약점 모니터링 주기 (CVE 검토)
-   - 보안 사고 대응 절차
+3. Section 5 (Configuration Management): 형상관리 상세 정책·절차는 Configuration Management Plan
+   을 참조. 이 섹션은 개발 워크플로우 수준의 개요(Git 브랜치 전략이 CMP 기준을 따른다는 정도)만 기술.
+4. 보안(Security): 본 SDP에 보안 챕터를 두지 않음. 보안 계획·정책·위협 모델링은
+   Security Management Plan (IEC 81001-5-1) 참조.
 5. Section 2.1 팀 구성에 실제 인원을 기재하고 역할을 구체화하세요
 
 완성 체크리스트:
   [ ] 제품명 및 SW 안전 등급 명시
   [ ] Design Phases에 PA/EA/ER/CA Gate 반영
-  [ ] Section 5 형상관리 상세 기술 (Git 브랜치, 버전 체계)
-  [ ] 사이버보안 챕터 추가 (IEC 81001-5-1)
+  [ ] Section 5 형상관리는 Configuration Management Plan 참조 확인
+  [ ] Security Management Plan (IEC 81001-5-1) 참조 확인
   [ ] 담당자 역할(R&R) 기재
 -->
 
@@ -166,21 +162,13 @@ The software's lifetime is established to be \[for example: three years\]. This
 > name versions and how you tag them. Your goal should be that you can retrieve an old version and build
 > it. Why? Something with a newer version may go wrong (harm patients) and you may need to roll back.
 
-*git is used as version control software. All source code and build files are committed to version control.*
+형상관리(식별·변경 통제·상태 기록·감사)의 상세 정책과 절차는 **Configuration Management Plan**
+을 따른다. 본 섹션에서는 개발 워크플로우 수준의 개요만 기술한다.
 
-*When implementing software requirements, developers create a new branch starting at master. During
-development, developers may create intermediate commits on this development branch.*
-
-*When implementation is completed, a new merge commit to master is created.*
-
-***This is also the activity which constitutes integration of software units.***
-
-*For each release, the goal is to be able to uniquely identify it and retrieve all relevant files (code,
-configuration files like build scripts, SOUPs, etc.) at any time in the future.*
-
-*When a new software version is released, its commit is tagged in git. The tag is constructed by adhering to
-semver ([semver.org](https://semver.org)) 2.0.0 which results in a version of format MAJOR.MINOR.PATCH,
-e.g., 1.0.0.*
+* Git을 버전 관리 도구로 사용. 모든 소스 코드·빌드 파일은 버전 관리 대상.
+* 개발자는 `master`에서 분기한 피처 브랜치에서 작업. 구현 완료 시 `master`로 머지 커밋 생성.
+* 각 release는 고유 식별 가능하도록 tag 부여(SemVer 2.0.0). 버전 체계·태그 정책·변경 통제 절차의
+  상세는 Configuration Management Plan §3·§4를 참조.
 
 ## 6 Documentation Activities