@neobiotechlabs/neobiotech-dev-agent-codex 0.1.39

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/algorithm-validation-report.md

@@ -0,0 +1,170 @@
+> DISCLAIMER:
+>
+> You may not need this template. It's aimed companies that develop devices including ML algorithms. Why do
+> they need this template?
+>
+> Due to the "blackbox" nature of many of those algorithms, their functionalities typically can't be verified
+> in the same sense as code reviews can verify correct coding in the world of old-school software
+> development. That's why they can only be validated by subjecting the model to rigorous testing on separate
+> test datasets. This report is the place to document all the results (e.g. sensitivity, specificity,
+> accuracy, ROC curve values, discussion of outlayers, edge cases, etc.). Side note: there's a disconnect
+> between what data science and regulatory affairs understands as validation and verification. Don't get
+> confused!
+
+# 1. General Information
+
+This document describes the specification of our machine learning (algorithm) model and its testing strategy.
+
+> Keep in mind that the results of the algorithm validation should also serve as input to and be referenced in
+> your clinical evaluation / performance evaluation report.
+
+**Regulatory references:**
+
+| ISO 13485:2016 Section   | Document Section |
+|--------------------------|------------------|
+| 6.2; 7.3.2               | 2.1              |
+| 7.3.7                    | 2.3; 3.1; 3.2    |
+| 4.2.3; 5.2; 7.2.1; 7.3.3 | 2.4              |
+| 4.1; 7.3.6               | 3                |
+| 7.3.2; 7.3.6; 7.3.7      | 5                |
+
+| ISO 14971:2019 Section | Document Section |
+|------------------------|------------------|
+| 4.3                    | 2.1              |
+| 5.2                    | 2.4              |
+
+| ISO 82304:2016 Section | Document Section |
+|------------------------|------------------|
+| 6.1                    | 2.1              |
+
+| ISO 62366-1:2015 Section | Document Section |
+|--------------------------|------------------|
+| 5.1; 5.2                 | 2.4              |
+
+| ISO 62304:2006 Section | Document Section |
+|------------------------|------------------|
+| 5.3; 8.1.2             | 2.2              |
+| 5.2                    | 2.4              |
+
+| ISO/IEC 24028:2020 Section | Document Section |
+|----------------------------|------------------|
+| 9.8.1; 10.5                | 3.1; 3.2         |
+| 9.8.2.1                    | 3.2              |
+| 9.8.2.2                    | 4                |
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* Software Development and Maintenance Plan
+* SOUP List
+
+# 2. Development Resources
+
+For more context information, refer to the device’s software development and maintenance plan.
+
+## 2.1. Developer Team
+
+| Name  | Role  | Qualification |
+|-------|-------|---------------|
+| (...) | (...) | (...)         |
+
+## 2.2. SOUP / Frameworks
+
+| Name    | Version |
+|---------|---------|
+| PyTorch | (...)   |
+
+## 2.3. Data
+
+| Count | Description                                           |
+|-------|-------------------------------------------------------|
+|       | \<e.g. annotated heart rate dataset from a wearable\> |
+
+## 2.4. Development Planning
+
+Optional: remove or add to the following sub-paragraphs as appropriate.
+
+**Intended Purpose**
+
+> Reference intended use; describe intended task the model should solve.
+
+(...)
+
+**Clinical Environment**
+
+> Reference clinical evaluation plan; describe clinical context in which the model will be used.
+
+(...)
+
+**Software Architecture**
+
+> Reference software architecture (diagram); describe how the model will be embedded in the overall system and
+> how it will interact with other software components.
+
+(...)
+
+**Quality Requirements**
+
+> Reference clinical evaluation plan; describe quality criteria that shall apply to the model, for example,
+> quantify values for sensitivity / specificity, AUC, positive/negative predictive value, accuracy,
+> repeatability. Also, provide justification for why certain parameters may not apply and compare your
+> approach to the current state of the art / technology.
+
+(...)
+
+# 3. Data Management
+
+## 3.1. Data Acquisition
+
+> Describe how you acquired your data (sources, inclusion / exclusion criteria, possible biases, data
+> protection measures, etc). Give a rough estimate of what size of datasets are required.
+>
+> If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.2. Data Annotation
+
+> Describe how data is labeled and how you determined the ground truth. Further, you can describe: labeling
+> requirements (quality criteria), qualification / training of staff involved, quality assurance for correct
+> labeling. If applicable, reference relevant QMS processes.
+
+(...)
+
+## 3.3. Data Pre-Processing
+
+> Describe how you pre-processed data. Possible steps may include: anonymization / pseudonymization, removing
+> data elements, converting data formats or units, handling missing values or data outliers. How did you
+> divide data into training, validation and test data. If applicable, reference relevant QMS processes.
+
+(...)
+
+# 4. Algorithm Model Training and Description
+
+> Describe your algorithm model. For example: which type of model (e.g. CNN) is used? Optionally, add a graph
+> or diagram to explain the model architecture. Describe model training; e.g. selection of features, (most
+> important) hyperparameters, etc.
+
+(...)
+
+# 5. Algorithm Model Evaluation
+
+> Describe how testing is done: describe your test data set, which metrics are used for evaluation and which
+> values are deemed acceptable.
+
+(...)
+
+# 6. Conclusion
+
+> Discuss your evaluation results: why do they meet predefined quality criteria, why is the model fit for
+> purpose in accordance with the medical device’s intended use? Take into account possible risks, biases and
+> limitations.
+
+(...)
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/checklist-software-release.md

@@ -0,0 +1,52 @@
+# Checklist: Software Release
+
+| Classes | IEC 62304:2006 Section | Document Section |
+| ------- | ---------------------- | ---------------- |
+| A, B, C | 5.8.1 | (All) |
+| A, B, C | 5.8.2 | (All) |
+| A, B, C | 5.8.3 | (All) |
+| A, B, C | 5.8.4 | (All) |
+| B, C | 5.8.5 | (All) |
+| B, C | 5.8.6 | (All) |
+| A, B, C | 5.8.7 | (All) |
+
+## Summary
+
+This checklist is used to verify that documentation and activities are complete before releasing a new version of the product.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The main point is that, at minimum, the items below should be checked (and documented) before you release a new version of your software.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty much the bare minimum to be 62304-compliant.
+
+## Checklist
+
+The following documents are up to date:
+
+> The table below shows examples only. Add - or reference - a list of all your required TechDoc records.
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| Device Description |  |  |  |
+| Clinical Evaluation |  |  |  |
+| Declaration of Conformity |  |  |  |
+| (...) |  |  |  |
+
+The following activities have been performed:
+
+| Item | Yes | No | Comment |
+| ---- | --- | --- | ------- |
+| All relevant functionalities of the software have been specified; the Software Requirement List is complete and has been reviewed. |  |  |  |
+| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. |  |  |  |
+| Verification (as software system testing) has been completed. |  |  |  |
+| Design control traceability is ensured:<br>Stakeholder requirements can be traced to software requirements.<br>Software requirements can be traced to system tests.<br>Software requirements can be traced to software code implementation / software code reviews.<br>Software requirements can be traced to risks and risk control measures.<br>Stakeholder requirements can be traced to usability tests.<br>Hazard-related use scenarios can be traced to usability tests.<br>Hazard-related use scenarios can be traced to risks and risk control measures. |  |  |  |
+| A version number as defined in the Software Development Plan has been assigned and added as a tag to git. |  |  |  |
+| Software is registered with a Notified Body. |  |  |  |
+| If release includes substantial change: Notified Body has been informed. |  |  |  |
+| Label is applied correctly including CE marking. |  |  |  |
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/checklist-software-requirements-review.md

@@ -0,0 +1,50 @@
+# Checklist: Software Requirements Review
+
+| Classes | IEC 62304:2006 Section | Document Section |
+|---------|------------------------|------------------|
+| A, B, C | 5.2.6                  | (All)            |
+
+| ISO 13485:2016 Section | Document Section |
+|------------------------|------------------|
+| 7.3.3                  | (All)            |
+| 7.3.5                  | (All)            |
+
+## 1. Summary
+
+This checklist is used to review (verify) software requirements prior to implementation.
+
+> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill
+> this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The
+> main point is that, at minimum, the items below should be filled out before you start implementing software
+> requirements.
+
+> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty
+> much the bare minimum to be 62304-compliant.
+
+## 2. Checklist
+
+| Software Requirements...                                                      | Yes | No | Comment |
+|-------------------------------------------------------------------------------|-----|----|---------|
+| are traceable to design input or risk control measures.                       |     |    |         |
+| are complete.                                                                 |     |    |         |
+| are understandable, uniquely identifiable and do not contradict each other.   |     |    |         |
+| include user interface requirements (mockups, wireframes, etc.), if relevant. |     |    |         |
+| include IT security requirements, if relevant.                                |     |    |         |
+| are testable and include acceptance criteria.                                 |     |    |         |
+
+# 3. Comments
+
+\<Insert comments if applicable\>
+
+# 4. Result
+
+[ ] Software Requirements passed\
+[ ] Software Requirements not passed\
+[ ] Software Requirements passed with the following obligations: \<Insert if applicable\>\
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/software-architecture-checklist.md

@@ -0,0 +1,41 @@
+# Software Architecture Checklist
+
+**Regulatory references:**
+
+IEC 62304, para. 5.3.6 [class B, C]
+
+**Relevant other documentation:**
+
+* SOP Software Development
+* User needs / stakeholder requirements
+* Design input / software requirements
+* Software architecture description
+* (...)
+
+# 1. Checklist
+
+| Criteria                                                                                                 | Pass / Fail             |
+|----------------------------------------------------------------------------------------------------------|-------------------------|
+| The software architecture is in agreement with the software requirements.                                | ( ) Yes<br>( ) Improve: |
+| All software systems are listed and their respective safety class is stated.                             | ( ) Yes<br>( ) Improve: |
+| All software components are listed and described, including interfaces.                                  | ( ) Yes<br>( ) Improve: |
+| All software units are listed and described.                                                             | ( ) Yes<br>( ) Improve: |
+| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes<br>( ) Improve: |
+| The software architecture can be implemented with our given resources.                                   | ( ) Yes<br>( ) Improve: |
+
+# 2. Comments
+
+\<Insert comments if applicable\>
+
+# 3. Results
+
+( ) Software Architecture passed\
+( ) Software Architecture not passed\
+( ) Software Architecture passed with the following obligations: \<Insert if applicable\>\
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/software-system-test-plan.md

@@ -0,0 +1,155 @@
+# Software System Test Plan & Protocol: {PRODUCT_NAME} v{VERSION}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.7 기반 시스템 테스트 계획서입니다.
+Sprint마다 테스트 케이스를 추가/업데이트하세요.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - SW 요구사항 명세서(software-requirements-list.md): 모든 SRS ID를 테스트 케이스로 커버해야 함
+  - FMEA(risk-table-fmea.md): 위험 통제 조치가 구현되었는지 검증하는 테스트 포함
+  - 사이버보안 체크리스트(risk-management-cybersecurity-checklist.md): 보안 테스트 항목 반영
+
+작성 지침:
+1. 모든 SRS 요구사항(SRS-F-xxx, SRS-P-xxx 등)에 최소 1개의 테스트 케이스가 있어야 합니다
+2. 테스트 ID 체계: TST-SYS-{N:3d} (예: TST-SYS-001)
+3. 테스트 결과 컬럼은 실제 테스트 실행 후 채워주세요 (계획서는 Expected까지만)
+4. 위험 통제 조치에 대한 테스트는 "위험 통제 검증?" 열을 Yes로 표시하세요
+5. Pass/Fail 외에 Blocked(사전 조건 미충족), N/A(해당 없음)도 사용 가능합니다
+
+테스트 카테고리:
+  - Functional: SRS-F-xxx 기능 요구사항 검증
+  - Performance: SRS-P-xxx 성능 요구사항 검증
+  - Security: SRS-S-xxx 보안 요구사항 검증
+  - Regression: 이전 버전에서 동작하던 기능이 유지되는지 확인
+  - Boundary: 경계값 조건 검증 (허용 범위 초과/미만 입력)
+
+테스트 환경 (필수 기재):
+  - 테스트 환경은 실제 사용 환경과 유사해야 합니다 (IEC 62304 Cl.5.7.2)
+  - 사용된 SOUP 버전을 명시하세요 (SOUP 리스트와 일치 확인)
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft (계획) / Final (프로토콜)
+**Sprint**: {SPRINT_NUMBER} | **작성일**: {DATE}
+**테스터**: {TESTER} | **검토자**: {REVIEWER}
+
+---
+
+## 표준 요건 매핑
+
+| 표준 조항          | 제목                          | 해당 섹션          |
+| ------------------ | ----------------------------- | ------------------ |
+| IEC 62304 Cl.5.7.1 | 통합 시스템 테스트 절차 수립  | 전체               |
+| IEC 62304 Cl.5.7.2 | 소프트웨어 시스템 테스트 수행 | 3. 테스트 케이스   |
+| IEC 62304 Cl.5.7.4 | 테스트 결과와 요구사항 추적성 | 4. 추적성 매트릭스 |
+| MDR Annex II 6.1   | 제품 검증                     | 전체               |
+
+---
+
+## 1. 테스트 환경 (Test Environment)
+
+<!-- AI AGENT: 실제 테스트를 수행한 환경을 정확하게 기재하세요 -->
+
+| 항목               | 사양                               |
+| ------------------ | ---------------------------------- |
+| OS / 환경          | {OS_VERSION}                       |
+| 주요 SOUP 버전     | {SOUP_NAME} v{VERSION} (SOUP-{ID}) |
+| 브라우저 / 런타임  | {BROWSER_OR_RUNTIME}               |
+| 테스트 데이터 출처 | {TEST_DATA_SOURCE}                 |
+| 테스트 실행 일시   | {TEST_DATE}                        |
+
+---
+
+## 2. 테스트 범위 (Test Scope)
+
+| 포함                         | 제외                                 |
+| ---------------------------- | ------------------------------------ |
+| {IN_SCOPE_TEST}              | {OUT_OF_SCOPE_TEST}                  |
+| SRS-F-xxx 전체 기능 요구사항 | 유닛 레벨 테스트 (별도 SDD에서 관리) |
+
+---
+
+## 3. 테스트 케이스 (Test Cases)
+
+### 3.1 기능 테스트 (Functional Tests)
+
+<!-- AI AGENT: 각 SRS-F-xxx 요구사항에 대한 테스트 케이스를 작성하세요
+테스트 단계(Steps)는 재현 가능하도록 구체적으로 작성해야 합니다
+예시:
+  Steps: 1. {URL}에 접속한다 2. 사용자 ID {ID}와 비밀번호 {PW}를 입력한다 3. 로그인 버튼을 클릭한다
+  Expected: 대시보드 페이지로 이동하고 사용자 이름이 표시된다 -->
+
+| 테스트 ID   | SRS ID    | 테스트 카테고리 | 테스트 설명   | 사전 조건   | 테스트 단계                | 예상 결과    | 위험 통제 검증? | 실제 결과 | Pass? |
+| ----------- | --------- | --------------- | ------------- | ----------- | -------------------------- | ------------ | --------------- | --------- | ----- |
+| TST-SYS-001 | SRS-F-001 | Functional      | {TEST_DESC_1} | {PRECOND_1} | 1. {STEP_1}<br>2. {STEP_2} | {EXPECTED_1} | Yes / No        |           |       |
+| TST-SYS-002 | SRS-F-002 | Functional      | {TEST_DESC_2} | {PRECOND_2} | 1. {STEP_1}<br>2. {STEP_2} | {EXPECTED_2} | No              |           |       |
+
+### 3.2 성능 테스트 (Performance Tests)
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 설명    | 허용 기준 | 측정 방법            | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------- | --------- | -------------------- | --------- | ----- |
+| TST-SYS-P-001 | SRS-P-001 | Performance     | 응답 시간 측정 | <= {N}초  | {MEASUREMENT_METHOD} | {ACTUAL}  |       |
+
+### 3.3 보안 테스트 (Security Tests)
+
+<!-- AI AGENT: SRS-S-xxx 보안 요구사항에 대한 테스트를 작성하세요
+다음 항목을 포함하는 것을 권장합니다:
+- 인증 실패 케이스 (잘못된 자격증명, 세션 만료)
+- 권한 없는 접근 시도
+- SQL Injection / XSS 방어 확인
+- TLS 통신 암호화 확인 -->
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 설명          | 예상 결과                              | 위험 통제 검증? | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------------- | -------------------------------------- | --------------- | --------- | ----- |
+| TST-SYS-S-001 | SRS-S-001 | Security        | {SECURITY_TEST_1}    | {EXPECTED}                             | Yes             |           |       |
+| TST-SYS-S-002 | SRS-S-002 | Security        | TLS 통신 암호화 확인 | Wireshark 캡처 시 암호화된 패킷만 관측 | Yes             |           |       |
+
+### 3.4 경계값 테스트 (Boundary Tests)
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 조건    | 입력값       | 예상 결과         | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------- | ------------ | ----------------- | --------- | ----- |
+| TST-SYS-B-001 | SRS-F-{N} | Boundary        | 최대값 입력    | {MAX_VALUE}  | {EXPECTED}        |           |       |
+| TST-SYS-B-002 | SRS-F-{N} | Boundary        | 최소값 입력    | {MIN_VALUE}  | {EXPECTED}        |           |       |
+| TST-SYS-B-003 | SRS-F-{N} | Boundary        | 범위 초과 입력 | {OVER_VALUE} | 오류 처리 및 거부 |           |       |
+
+---
+
+## 4. 추적성 매트릭스 (Traceability Matrix)
+
+<!-- AI AGENT: 모든 SRS 요구사항이 테스트에 의해 커버되는지 확인하세요 -->
+
+| SRS ID    | 요구사항 설명  | 테스트 ID     | 위험 ID   | 커버 여부 |
+| --------- | -------------- | ------------- | --------- | --------- |
+| SRS-F-001 | {REQ_DESC}     | TST-SYS-001   | -         | Yes       |
+| SRS-S-001 | {SEC_REQ_DESC} | TST-SYS-S-001 | {RISK_ID} | Yes       |
+
+---
+
+## 5. 테스트 결과 요약 (Test Results Summary)
+
+<!-- AI AGENT: 테스트 완료 후 아래 표를 채워주세요 -->
+
+| 카테고리    | 전체 | Pass | Fail | Blocked | N/A |
+| ----------- | ---- | ---- | ---- | ------- | --- |
+| Functional  | {N}  |      |      |         |     |
+| Performance | {N}  |      |      |         |     |
+| Security    | {N}  |      |      |         |     |
+| Boundary    | {N}  |      |      |         |     |
+| **합계**    |      |      |      |         |     |
+
+**결론**: Pass / Fail / Conditional Pass
+
+**미해결 결함 목록**: (없음 또는 bug-fixes-documentation-list.md 참조)
+
+---
+
+## 6. 변경 이력
+
+| 버전 | 날짜   | 작성자   | 변경 내용             |
+| ---- | ------ | -------- | --------------------- |
+| 0.1  | {DATE} | {AUTHOR} | 계획서 초안           |
+| 1.0  | {DATE} | {TESTER} | 테스트 결과 입력 완료 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Clause 5.7, MDR 2017/745 Annex II 6.1

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/usability-evaluation-protocol.md

@@ -0,0 +1,63 @@
+# Usability Evaluation Protocol
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                         | Document Section |
+|--------------------------|-----------------------------------------------|------------------|
+| 4.2                      | Usability Engineering File                    | (all)            |
+| 4.3                      | Tailoring of the Usability Engineering effort | (all)            |
+
+## 1. User Group and Environment
+
+> Describe the user group here, e.g., physicians with experience in a certain field.
+
+> Also, describe the environment in which the user test is being conducted. Obviously, both the user group and
+> environment should match whatever you described in your Intended Use. So, if your app is intended to be used
+> by emergency physicians in a brightly-lit hospital environment, you should also have these people do the
+> usability test in a similar environment.
+
+## 2. Preparation
+
+> Describe whether you prepare users in any way. Again, this should be based on the use context in which your
+> users will be using your device in real life. So, if people typically carefully read the user manual before
+> (not sure in which parallel universe that happens), you can give them the manual and some time to study
+> it. More realistically, you'll probably test how users handle your device when they haven't read the manual.
+
+> If there are official training which are required before users can use your device, you should do this
+> training first, of course.
+
+## 3. List of Tasks
+
+> This table lists the tasks you want your users to perform. It's kind of the master table which will be
+> copy-pasted for each user below - you'll be filling out the observations and hazards encountered by each
+> user.
+
+> As always, using a spreadsheet (e.g., Google Sheets) instead of a document is a very good idea here.
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+## 4. Protocols
+
+> Copy-paste the table above for each user and fill it out during the test. Note down the names and ages (or
+> any other important characteristics) per user.
+
+### User 1 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+### User 2 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

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       |         |