arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/framework-overview-template.md

@@ -0,0 +1,247 @@
+# Framework Overview: [PROJECT_NAME]
+
+> **Template Origin**: Official | **ArcKit Version**: [VERSION] | **Command**: `/arckit:framework`
+
+## Document Control
+
+<!-- DOC-CONTROL-HEADER -->
+<!-- Resolved at command-execution time to _partials/document-control-uk.md or _partials/document-control-uae.md based on plugin userConfig classification_scheme + governance_framework. See _partials/RENDERING.md (when present). -->
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [DATE] | ArcKit AI | Initial creation from `/arckit:framework` command | [PENDING] | [PENDING] |
+
+---
+
+## Executive Summary
+
+### Vision
+
+[1-2 paragraphs describing the overarching vision for this framework. What transformation or capability does it enable? What future state does it support?]
+
+### Challenge Being Addressed
+
+[Description of the problem, gap, or challenge that this framework addresses. Why is a structured framework needed? What are the consequences of not having one?]
+
+### Solution Approach
+
+[Overview of how the framework addresses the challenge. What methodology, structure, or approach does it take? How does it differ from previous efforts?]
+
+### Scope
+
+[Define the boundaries of the framework. What is in scope? What is explicitly out of scope? Which teams, systems, or processes does it cover?]
+
+- **In Scope**: [List of areas, teams, systems, or processes covered]
+- **Out of Scope**: [List of areas explicitly excluded]
+- **Dependencies**: [External frameworks, standards, or systems this framework depends on]
+
+---
+
+## Framework Architecture
+
+### Dimensions and Axes
+
+[Describe the primary dimensions or axes along which the framework is organised. For example, a data framework might have dimensions of Data Governance, Data Quality, Data Integration, and Data Analytics. A security framework might have dimensions of Identify, Protect, Detect, Respond, and Recover.]
+
+| Dimension | Purpose | Key Outcomes |
+|-----------|---------|--------------|
+| [Dimension 1] | [What this dimension addresses] | [Expected outcomes] |
+| [Dimension 2] | [What this dimension addresses] | [Expected outcomes] |
+| [Dimension 3] | [What this dimension addresses] | [Expected outcomes] |
+| [Dimension 4] | [What this dimension addresses] | [Expected outcomes] |
+
+### Layers
+
+[Describe the layers of the framework, from strategic to operational.]
+
+| Layer | Description | Audience |
+|-------|-------------|----------|
+| [Strategic Layer] | [High-level direction, principles, and governance] | [Senior leadership, architects] |
+| [Tactical Layer] | [Policies, standards, and patterns] | [Managers, lead engineers] |
+| [Operational Layer] | [Procedures, tools, and implementation guides] | [Delivery teams, practitioners] |
+
+### Cross-Cutting Concerns
+
+[Identify concerns that span all dimensions and layers of the framework.]
+
+- **Governance**: [How governance applies across the framework]
+- **Security**: [How security is embedded throughout]
+- **Compliance**: [Regulatory and standards compliance approach]
+- **Change Management**: [How changes to the framework are managed]
+
+### Framework Architecture Diagram
+
+```mermaid
+graph TB
+    subgraph "Framework Architecture"
+        subgraph "Phase 1: Foundation"
+            F1[Component 1]
+            F2[Component 2]
+        end
+        subgraph "Phase 2: [Phase Name]"
+            P1[Component 3]
+            P2[Component 4]
+        end
+        subgraph "Cross-Cutting Concerns"
+            CC1[Governance]
+            CC2[Security]
+        end
+    end
+```
+
+---
+
+## Design Philosophy
+
+### Systems Thinking Foundations
+
+This framework is shaped by four foundational systems thinking laws:
+
+| Law | Principle | How Applied |
+|-----|-----------|-------------|
+| **Ashby's Law of Requisite Variety** | "Only variety can absorb variety" — a governance framework must have at least as much variety in its controls as the system it governs | [How the framework's control variety matches the system's complexity — see Requisite Variety Assessment below] |
+| **Conant-Ashby Good Regulator Theorem** | "Every good regulator of a system must be a model of that system" — the framework must accurately represent the system it governs | [How the framework models the actual system architecture, components, and relationships — verified via Document Map and Traceability] |
+| **Gall's Law** | "A complex system that works is invariably found to have evolved from a simple system that worked" — start simple, layer on complexity | [How phased adoption ensures each phase is independently viable before building on it] |
+| **Conway's Law** | "Organizations produce designs that mirror their communication structures" — framework adoption must align with organisational reality | [How adoption paths and phase boundaries respect team structure and communication patterns] |
+
+### Key Design Decisions
+
+[Describe the fundamental design decisions that shaped this framework. Why was this structure chosen over alternatives? What trade-offs were made?]
+
+| Decision | Choice | Rationale |
+|----------|--------|-----------|
+| [Decision 1] | [Choice made] | [Why this choice was made] |
+| [Decision 2] | [Choice made] | [Why this choice was made] |
+| [Decision 3] | [Choice made] | [Why this choice was made] |
+
+### Requisite Variety Assessment
+
+> **Ashby's Law of Requisite Variety**: "Only variety can absorb variety." A governance framework must have at least as much variety in its controls, principles, and guidance as the system it governs.
+
+The following table maps the project's identified concern domains against the framework's governance controls:
+
+| Domain | System Variety (Concerns Identified) | Framework Controls (Artifacts / Governance) | Coverage |
+|--------|--------------------------------------|---------------------------------------------|----------|
+| [e.g., Security] | [Concerns from requirements, stakeholders, risks] | [Artifacts addressing this domain] | [COVERED / PARTIAL / GAP] |
+| [e.g., Data Governance] | [Concerns from requirements, stakeholders, risks] | [Artifacts addressing this domain] | [COVERED / PARTIAL / GAP] |
+| [e.g., Compliance] | [Concerns from requirements, stakeholders, risks] | [Artifacts addressing this domain] | [COVERED / PARTIAL / GAP] |
+| [e.g., Operations] | [Concerns from requirements, stakeholders, risks] | [Artifacts addressing this domain] | [COVERED / PARTIAL / GAP] |
+
+**Coverage Summary**: [Statement on whether the framework has requisite variety. Identify any domains where system variety exceeds framework control variety, and recommend additional artifacts or governance mechanisms to close the gaps.]
+
+### Good Regulator Check
+
+> **Conant-Ashby Theorem**: "Every good regulator of a system must be a model of that system."
+
+[Assessment of whether this framework faithfully models the system it governs. Does the Document Map represent every significant system component? Are relationships and dependencies between components reflected in the phase structure? Identify any aspects of the system that are not represented in the framework's governance structure.]
+
+### Guiding Principles Alignment
+
+| Principle | How Applied | Framework Impact |
+|-----------|-------------|------------------|
+| [Principle 1 from ARC-000-PRIN] | [How this principle is applied within the framework] | [What impact it has on framework design] |
+| [Principle 2 from ARC-000-PRIN] | [How this principle is applied within the framework] | [What impact it has on framework design] |
+| [Principle 3 from ARC-000-PRIN] | [How this principle is applied within the framework] | [What impact it has on framework design] |
+| [Principle 4 from ARC-000-PRIN] | [How this principle is applied within the framework] | [What impact it has on framework design] |
+
+---
+
+## Document Map
+
+The following documents form the complete framework, organised by phase:
+
+| Phase | Document | Doc Type | Description |
+|-------|----------|----------|-------------|
+| Foundation | [Document 1] | [e.g., Principles, Policy] | [Brief description of document purpose] |
+| Foundation | [Document 2] | [e.g., Standards, Guidelines] | [Brief description of document purpose] |
+| Definition | [Document 3] | [e.g., Architecture, Data Model] | [Brief description of document purpose] |
+| Definition | [Document 4] | [e.g., Requirements, Patterns] | [Brief description of document purpose] |
+| Implementation | [Document 5] | [e.g., Procedures, Runbooks] | [Brief description of document purpose] |
+| Implementation | [Document 6] | [e.g., Templates, Checklists] | [Brief description of document purpose] |
+| Operations | [Document 7] | [e.g., Monitoring, Review] | [Brief description of document purpose] |
+| Operations | [Document 8] | [e.g., Metrics, Reporting] | [Brief description of document purpose] |
+
+---
+
+## Standards Alignment
+
+| Standard | Version | How Used | URL |
+|----------|---------|----------|-----|
+| [Standard 1] | [Version] | [How this standard is applied or referenced] | [URL] |
+| [Standard 2] | [Version] | [How this standard is applied or referenced] | [URL] |
+| [Standard 3] | [Version] | [How this standard is applied or referenced] | [URL] |
+| [Standard 4] | [Version] | [How this standard is applied or referenced] | [URL] |
+
+---
+
+## Adoption Guidance
+
+### How to Adopt the Framework
+
+[Describe the recommended approach for adopting this framework. Is it intended for incremental adoption or full implementation? What is the minimum viable adoption?]
+
+### Entry Points by Role
+
+| Role | Start With | Then | Goal |
+|------|------------|------|------|
+| [Executive / Sponsor] | [First document or activity] | [Next steps] | [What success looks like for this role] |
+| [Architect / Lead] | [First document or activity] | [Next steps] | [What success looks like for this role] |
+| [Developer / Practitioner] | [First document or activity] | [Next steps] | [What success looks like for this role] |
+| [Operations / Support] | [First document or activity] | [Next steps] | [What success looks like for this role] |
+| [Governance / Compliance] | [First document or activity] | [Next steps] | [What success looks like for this role] |
+
+### Phased Adoption Approach
+
+| Phase | Focus | Activities | Duration | Success Criteria |
+|-------|-------|------------|----------|------------------|
+| Phase 1: Awareness | Understanding the framework | [Key activities] | [Timeframe] | [Measurable criteria] |
+| Phase 2: Foundation | Establishing core practices | [Key activities] | [Timeframe] | [Measurable criteria] |
+| Phase 3: Implementation | Embedding into operations | [Key activities] | [Timeframe] | [Measurable criteria] |
+| Phase 4: Optimisation | Continuous improvement | [Key activities] | [Timeframe] | [Measurable criteria] |
+
+---
+
+## Traceability
+
+### Source Documents
+
+| Source Document | Document ID | Key Contributions |
+|-----------------|-------------|-------------------|
+| Architecture Principles | ARC-000-PRIN-v[N].md | Guiding principles, decision framework |
+| Stakeholder Analysis | ARC-[PID]-STKE-v[N].md | Stakeholder needs, goals, communication plans |
+| Requirements | ARC-[PID]-REQ-v[N].md | Business, functional, and non-functional requirements |
+| Risk Register | ARC-[PID]-RISK-v[N].md | Risks, mitigations, and constraints |
+| [Additional Source] | [Document ID] | [Key contributions to the framework] |
+
+## External References
+
+> This section provides traceability from generated content back to source documents.
+> Follow citation instructions in the project's citation reference guide.
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| *None provided* | — | — | — | — |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:framework` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/gap-analysis-template.md

@@ -0,0 +1,198 @@
+---
+title: "Gap Analysis"
+docType: GAPA
+templateVersion: "1.0"
+---
+
+# Gap Analysis
+
+## Document Control
+
+| Field | Value |
+|-------|-------|
+| Document ID | `ARC-[PROJECT_ID]-GAPA-v[VERSION]` |
+| Project | `[PROJECT_NAME]` |
+| Owner | `[OWNER_NAME_AND_ROLE]` |
+| Classification | `[CLASSIFICATION]` |
+| Status | DRAFT |
+| Severity Weighting | `[BALANCED / STRATEGIC-RISK / OPERATIONAL]` |
+| Created | `[YYYY-MM-DD]` |
+| Review Date | `[YYYY-MM-DD]` |
+
+### Revision History
+
+| Version | Date | Author | Description | Reviewer | Approver |
+|---------|------|--------|-------------|----------|----------|
+| `[VERSION]` | `[YYYY-MM-DD]` | ArcKit AI | Initial creation from `/arckit:gap-analysis` command | `[REVIEWER_NAME]` | `[APPROVER_NAME]` |
+
+---
+
+## 1. Capability Gap Matrix
+
+| Capability | Current | Target | Gap Size | Urgency | Severity (Size×Urgency) | Workstream |
+|------------|---------|--------|----------|---------|--------------------------|------------|
+| C1.1.1: [Capability Name] | L2 | L4 | Medium | High | High | WS-001 |
+| C1.1.2: [Capability Name] | L3 | L4 | Small | Medium | Medium | WS-001 |
+| C2.1.1: [Capability Name] | L1 | L4 | Large | High | Critical | WS-002 |
+| C2.1.2: [Capability Name] | L2 | L3 | Small | Low | Low | WS-003 |
+| C3.1.1: [Capability Name] | L3 | L5 | Large | Medium | High | WS-002 |
+| C3.2.1: [Capability Name] | L4 | L5 | Small | High | Medium | WS-003 |
+| C4.1.1: [Capability Name] | L1 | L3 | Medium | High | High | WS-001 |
+| C4.2.1: [Capability Name] | L2 | L2 | None | Low | Informational | — |
+| C5.1.1: [Capability Name] | L3 | L5 | Medium | Low | Medium | WS-004 |
+
+### Gap Size Classification
+
+| Gap Size | Maturity Delta | Description |
+|----------|---------------|-------------|
+| Small | Δ = 1 level | Incremental improvement |
+| Medium | Δ = 2 levels | Significant enhancement required |
+| Large | Δ ≥ 3 levels | Fundamental transformation required |
+
+### Urgency Classification
+
+| Urgency | Description | Timeframe |
+|---------|-------------|-----------|
+| High | Must address in immediate planning horizon | 0–3 months |
+| Medium | Address in next delivery cycle | 3–12 months |
+| Low | Plan for future cycles | 12–24 months |
+
+### Severity Matrix
+
+| | Urgency: Low | Urgency: Medium | Urgency: High |
+|---|---|---|---|
+| **Gap Size: Small** | Informational | Medium | Medium |
+| **Gap Size: Medium** | Low | Medium | High |
+| **Gap Size: Large** | Plan | High | Critical |
+
+---
+
+## 2. Gap Heatmap
+
+```mermaid
+quadrantChart
+    title Gap Severity — Size vs Urgency
+    x-axis__Low --> High
+    y-axis__Low --> High
+    quadrant-1 Immediate
+    quadrant-2 Plan
+    quadrant-3 Monitor
+    quadrant-4 Low Priority
+    "C1.1.1": [0.5, 0.8]
+    "C2.1.1": [0.8, 0.9]
+    "C3.1.1": [0.7, 0.5]
+    "C4.1.1": [0.5, 0.7]
+    "C5.1.1": [0.5, 0.3]
+    "C1.1.2": [0.3, 0.5]
+    "C3.2.1": [0.3, 0.7]
+    "C2.1.2": [0.3, 0.2]
+```
+
+### Heatmap Interpretation
+
+| Quadrant | Count | Action |
+|----------|-------|--------|
+| **Immediate** (Large + High urgency) | [N] | Assign to next work package |
+| **Plan** (Large + Low urgency) | [N] | Include in 12-month planning |
+| **Monitor** (Small + High urgency) | [N] | Quick wins — address early |
+| **Low Priority** (Small + Low urgency) | [N] | Maintain in backlog |
+
+---
+
+## 3. Workstream Mapping
+
+| Workstream ID | Name | Gaps | Dependencies | Duration | Resources |
+|---------------|------|------|-------------|----------|-----------|
+| WS-001 | [Workstream Name] | [C1.1.1, C4.1.1] | [—] | [6 months] | [5 FTE] |
+| WS-002 | [Workstream Name] | [C2.1.1, C3.1.1] | [WS-001] | [9 months] | [8 FTE] |
+| WS-003 | [Workstream Name] | [C2.1.2, C3.2.1] | [WS-002] | [4 months] | [3 FTE] |
+| WS-004 | [Workstream Name] | [C5.1.1] | [WS-002] | [3 months] | [2 FTE] |
+
+### Workstream Dependencies
+
+```mermaid
+flowchart TD
+    WS1[WS-001: [Workstream 1 Name]] --> WS2[WS-002: [Workstream 2 Name]]
+    WS2 --> WS3[WS-003: [Workstream 3 Name]]
+    WS1 --> WS3
+    WS2 --> WS4[WS-004: [Workstream 4 Name]]
+```
+
+### Workstream Details
+
+#### WS-001: [Workstream Name]
+
+- **Objective**: [Brief description of what this workstream delivers]
+- **Gaps addressed**: [List capabilities]
+- **Key activities**:
+  1. [Activity 1]
+  2. [Activity 2]
+  3. [Activity 3]
+- **Success criteria**: [Measurable outcomes]
+
+#### WS-002: [Workstream Name]
+
+- **Objective**: [Brief description of what this workstream delivers]
+- **Gaps addressed**: [List capabilities]
+- **Key activities**:
+  1. [Activity 1]
+  2. [Activity 2]
+  3. [Activity 3]
+- **Success criteria**: [Measurable outcomes]
+
+---
+
+## 4. Gap-to-Risk Mapping
+
+| Gap | Capability | Associated Risk | Risk Category | Impact | Mitigation |
+|-----|-----------|-----------------|---------------|--------|----------|
+| G-001 | C1.1.1 | [Risk description] | [Operational/Strategic/Compliance] | [High/Medium/Low] | [Mitigation] |
+| G-002 | C2.1.1 | [Risk description] | [Operational/Strategic/Compliance] | [High/Medium/Low] | [Mitigation] |
+| G-003 | C3.1.1 | [Risk description] | [Operational/Strategic/Compliance] | [High/Medium/Low] | [Mitigation] |
+| G-004 | C4.1.1 | [Risk description] | [Operational/Strategic/Compliance] | [High/Medium/Low] | [Mitigation] |
+| G-005 | C5.1.1 | [Risk description] | [Operational/Strategic/Compliance] | [High/Medium/Low] | [Mitigation] |
+
+---
+
+## 5. Assumptions & Constraints
+
+### Assumptions
+
+1. [Assumption about current state assessment accuracy]
+2. [Assumption about target state feasibility]
+3. [Assumption about resource availability]
+4. [Assumption about technology stability]
+
+### Constraints
+
+1. **Budget**: [Budget constraints affecting gap closure]
+2. **Timeline**: [Time-based constraints on delivery]
+3. **Skills**: [Skills gaps that affect workstream execution]
+4. **Technology**: [Technology constraints and dependencies]
+5. **Compliance**: [Regulatory constraints on approach]
+
+---
+
+## 6. Traceability
+
+| Gap | Source Capability (BPCM) | Target State (STRAT) | Principle Alignment (PRIN) | Workstream |
+|-----|--------------------------|---------------------|-------------------------------|------------|
+| G-001 | C1.1.1 (L2 → L4) | STRAT Section 3.2 | PRIN-005 | WS-001 |
+| G-002 | C2.1.1 (L1 → L4) | STRAT Section 4.1 | PRIN-003 | WS-002 |
+| G-003 | C3.1.1 (L3 → L5) | STRAT Section 2.5 | PRIN-007 | WS-002 |
+| G-004 | C4.1.1 (L1 → L3) | STRAT Section 5.3 | PRIN-002 | WS-001 |
+| G-005 | C5.1.1 (L3 → L5) | STRAT Section 3.8 | PRIN-009 | WS-004 |
+
+### External References
+
+| ID | Source | Relevance |
+|----|--------|-----------|
+| [GA-E1] | [External document name] | [What it contributed] |
+
+---
+
+**Generated by**: ArcKit `/arckit:gap-analysis` command
+**Generated on**: `[DATE] [TIME] GMT`
+**ArcKit Version**: `{ARCKIT_VERSION}`
+**Project**: `[PROJECT_NAME]` (Project `[PROJECT_ID]`)
+**Severity Weighting Profile**: `[BALANCED / STRATEGIC-RISK / OPERATIONAL]`