@documentation-robotics/cli 0.1.0 → 0.1.7

package/dist/integrations/github_copilot/skills/dr_10_navigation_layer/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: LAYER_10_NAVIGATION
+description: Expert knowledge for Navigation Layer modeling in Documentation Robotics
+triggers:
+  [
+    "navigation",
+    "routing",
+    "route",
+    "flow",
+    "navigation guard",
+    "redirect",
+    "navigation flow"
+  ]
+version: 0.8.1
+---
+
+# Navigation Layer Skill
+
+**Layer Number:** 10
+**Specification:** Metadata Model Spec v0.8.1
+**Purpose:** Defines multi-modal navigation flows, routes, guards, and transitions between views.
+
+---
+
+## Layer Overview
+
+The Navigation Layer captures **navigation and routing**:
+
+- **ROUTES** - URL paths to views
+- **GUARDS** - Authorization checks before navigation
+- **FLOWS** - Multi-step navigation flows
+- **TRANSITIONS** - Navigation between routes
+- **REDIRECTS** - Conditional redirects
+- **CONTEXT** - Navigation context variables
+- **TRACKING** - Analytics and process tracking
+
+This layer uses **Multi-Modal Navigation** supporting web, mobile, voice, and other modalities.
+
+**Central Entity:** The **Route** (URL path to view) is the core modeling unit.
+
+---
+
+## Entity Types
+
+> **CLI Introspection:** Run `dr schema types navigation` for the authoritative, always-current list of node types.
+> Run `dr schema node <type-id>` for full attribute details on any type.
+
+### Core Navigation Entities (10 entities)
+
+| Entity Type              | Description                                |
+| ------------------------ | ------------------------------------------ |
+| **Route**                | URL path mapped to view                    |
+| **NavigationGuard**      | Authorization/validation before navigation |
+| **NavigationFlow**       | Multi-step navigation sequence             |
+| **NavigationTransition** | Transition between routes                  |
+| **FlowStep**             | Step in navigation flow                    |
+| **ContextVariable**      | Navigation context data                    |
+| **DataMapping**          | Data passing between routes                |
+| **NotificationAction**   | Navigation-triggered notifications         |
+| **ProcessTracking**      | Business process tracking                  |
+| **FlowAnalytics**        | Navigation analytics                       |
+
+---
+
+## When to Use This Skill
+
+Activate when the user:
+
+- Mentions "navigation", "routing", "routes", "flows"
+- Wants to define URL paths or route guards
+- Asks about multi-step flows or navigation transitions
+- Needs to model navigation between screens
+- Wants to link navigation to UX views or business processes
+
+---
+
+## Cross-Layer Relationships
+
+**Outgoing (Navigation → Other Layers):**
+
+- `view-ref` → UX Layer (which view does this route show?)
+- `business.realizes-process` → Business Layer (what process does this flow realize?)
+- `security.required-roles` → Security Layer (authorization requirements)
+- `apm.flow-metrics` → APM Layer (navigation analytics)
+
+**Incoming (Other Layers → Navigation):**
+
+- UX Layer → Navigation (views reference routes)
+- Business Layer → Navigation (processes trigger flows)
+
+---
+
+## Design Best Practices
+
+1. **Guards** - Add navigation guards for protected routes
+2. **Context** - Pass necessary context between routes
+3. **Analytics** - Track navigation flows for insights
+4. **Error handling** - Define fallback routes for errors
+5. **Deep linking** - Support deep linking for all routes
+6. **SEO** - Consider SEO requirements for public routes
+7. **Performance** - Lazy-load routes when appropriate
+
+---
+
+## Common Commands
+
+```bash
+# Add route
+dr add navigation route --name "User Profile Route" --property path=/profile/:id
+
+# Add navigation guard
+dr add navigation navigation-guard --name "Auth Guard"
+
+# Add navigation flow
+dr add navigation navigation-flow --name "Checkout Flow"
+
+# List routes
+dr list navigation route
+
+# Validate navigation layer
+dr validate --layer navigation
+
+# Export navigation map
+dr export --layer navigation --format mermaid
+```
+
+---
+
+## Example: Protected Profile Route
+
+```yaml
+id: navigation.route.user-profile
+name: "User Profile Route"
+type: route
+properties:
+  path: /profile/:userId
+  view-ref: ux.view.user-profile
+  guards:
+    - navigation.guard.authentication
+    - navigation.guard.profile-ownership
+  parameters:
+    - name: userId
+      type: string
+      format: uuid
+      required: true
+  meta:
+    title: "User Profile"
+    requiresAuth: true
+    allowedRoles:
+      - user
+      - admin
+  contextVariables:
+    - name: currentUserId
+      source: auth.user.id
+  dataMapping:
+    - source: route.params.userId
+      target: view.data.userId
+  security:
+    required-roles:
+      - security.role.authenticated-user
+  business:
+    realizes-process: business.process.profile-management
+  apm:
+    flow-metrics:
+      - apm.metric.profile-view-count
+      - apm.metric.profile-load-time
+```
+
+---
+
+## Example: Multi-Step Checkout Flow
+
+```yaml
+id: navigation.flow.checkout
+name: "Checkout Flow"
+type: navigation-flow
+properties:
+  steps:
+    - id: cart-review
+      route: /checkout/cart
+      view: ux.view.cart-review
+      onNext: validate-cart
+    - id: shipping-address
+      route: /checkout/shipping
+      view: ux.view.shipping-form
+      onNext: validate-address
+    - id: payment
+      route: /checkout/payment
+      view: ux.view.payment-form
+      onNext: validate-payment
+    - id: confirmation
+      route: /checkout/confirm
+      view: ux.view.order-confirmation
+      final: true
+  transitions:
+    - from: cart-review
+      to: shipping-address
+      trigger: next-button
+      guard: cart-not-empty
+    - from: shipping-address
+      to: payment
+      trigger: next-button
+      guard: valid-address
+    - from: payment
+      to: confirmation
+      trigger: submit
+      guard: payment-successful
+  context:
+    - cartId
+    - selectedAddress
+    - paymentMethod
+  analytics:
+    trackStepCompletion: true
+    trackAbandonmentRate: true
+  business:
+    realizes-process: business.process.checkout
+```
+
+---
+
+## Pitfalls to Avoid
+
+- ❌ Missing authentication guards on protected routes
+- ❌ Not validating route parameters
+- ❌ Complex flows without clear step definitions
+- ❌ Not tracking navigation analytics
+- ❌ Missing cross-layer links to UX views
+- ❌ No error/fallback routes defined

package/dist/integrations/github_copilot/skills/dr_11_apm_layer/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: LAYER_11_APM
+description: Expert knowledge for APM (Observability) Layer modeling in Documentation Robotics
+triggers:
+  [
+    "APM",
+    "observability",
+    "monitoring",
+    "metrics",
+    "spans",
+    "traces",
+    "logs",
+    "OpenTelemetry",
+    "telemetry"
+  ]
+version: 0.8.1
+---
+
+# APM Layer Skill
+
+**Layer Number:** 11
+**Specification:** Metadata Model Spec v0.8.1
+**Purpose:** Defines observability using OpenTelemetry 1.0+, specifying traces, metrics, logs, and instrumentation.
+
+---
+
+## Layer Overview
+
+The APM Layer captures **application performance monitoring**:
+
+- **TRACES** - Distributed tracing with spans
+- **METRICS** - Performance and business metrics
+- **LOGS** - Structured logging
+- **INSTRUMENTATION** - Code instrumentation configuration
+- **RESOURCES** - Telemetry resource attributes
+- **SLOs/SLAs** - Service level objectives and agreements
+
+This layer uses **OpenTelemetry 1.0+** (industry standard for observability).
+
+**Central Entity:** The **Span** (unit of work in trace) is the core modeling unit.
+
+---
+
+## Entity Types
+
+> **CLI Introspection:** Run `dr schema types apm` for the authoritative, always-current list of node types.
+> Run `dr schema node <type-id>` for full attribute details on any type.
+
+### Core APM Entities (14 entities)
+
+| Entity Type              | Description                                   |
+| ------------------------ | --------------------------------------------- |
+| **APMConfiguration**     | Root configuration for observability          |
+| **TraceConfiguration**   | Distributed tracing configuration             |
+| **Span**                 | Unit of work in distributed trace             |
+| **SpanEvent**            | Timestamped event within span                 |
+| **MetricConfiguration**  | Metrics collection configuration              |
+| **MeterConfig**          | Meter for metric instruments                  |
+| **InstrumentConfig**     | Metric instrument (counter, gauge, histogram) |
+| **LogConfiguration**     | Structured logging configuration              |
+| **LogRecord**            | Individual log record                         |
+| **Resource**             | Telemetry resource attributes                 |
+| **Attribute**            | Key-value telemetry attribute                 |
+| **InstrumentationScope** | Scope of instrumentation                      |
+| **DataQualityMetric**    | Data quality metrics                          |
+| **DataQualityMetrics**   | Collection of data quality metrics            |
+
+---
+
+## When to Use This Skill
+
+Activate when the user:
+
+- Mentions "APM", "observability", "monitoring", "telemetry"
+- Wants to add tracing, metrics, or logging
+- Asks about performance monitoring or SLOs
+- Needs to instrument code or track business metrics
+- Wants to link observability to application services
+
+---
+
+## Cross-Layer Relationships
+
+**Outgoing (APM → Other Layers):**
+
+- `instrumented-service` → Application Layer (which service is being monitored?)
+- `business-metrics` → Business Layer (business KPIs)
+
+**Incoming (Other Layers → APM):**
+
+- Application Layer → APM (services reference metrics)
+- API Layer → APM (operations set SLA targets)
+- Business Layer → APM (processes reference business metrics)
+- Data Model Layer → APM (data quality metrics)
+- Data Store Layer → APM (query performance metrics)
+
+---
+
+## Observability Best Practices
+
+1. **Traces** - Add spans for critical operations
+2. **Metrics** - Track both technical and business metrics
+3. **Logs** - Use structured logging (JSON)
+4. **Context** - Propagate trace context across services
+5. **Sampling** - Configure appropriate sampling rates
+6. **SLOs** - Define service level objectives
+7. **Alerting** - Set up alerts for critical metrics
+8. **Cardinality** - Avoid high-cardinality attributes
+
+---
+
+## Common Commands
+
+```bash
+# Add span
+dr add apm span --name "Process Order"
+
+# Add metric
+dr add apm instrument-config --name "order_rate" --property type=counter
+
+# Add log record
+dr add apm log-record --name "Error Log"
+
+# List APM elements
+dr list apm span
+
+# Validate APM layer
+dr validate --layer apm
+
+# Export APM configuration
+dr export --layer apm --format json
+```
+
+---
+
+## Example: Order Processing Span
+
+```yaml
+id: apm.span.process-order
+name: "Process Order Span"
+type: span
+properties:
+  spanKind: INTERNAL
+  operationName: process_order
+  attributes:
+    - key: order.id
+      type: string
+    - key: order.total
+      type: double
+    - key: customer.id
+      type: string
+  events:
+    - name: order_validated
+      timestamp: relative
+    - name: payment_processed
+      timestamp: relative
+    - name: inventory_reserved
+      timestamp: relative
+  instrumented-service: application.service.order-processing
+  business-metrics:
+    - apm.metric.orders-processed
+    - apm.metric.order-processing-time
+  sla-target-latency: 500ms
+  sla-target-availability: 99.9%
+```
+
+---
+
+## Example: Business Metrics
+
+```yaml
+id: apm.metric.order-rate
+name: "Order Rate Metric"
+type: instrument-config
+properties:
+  instrumentType: counter
+  unit: orders
+  description: "Number of orders processed"
+  attributes:
+    - key: order.type
+      type: string
+      values: [standard, express, subscription]
+    - key: payment.method
+      type: string
+      values: [credit_card, paypal, bank_transfer]
+  business-context:
+    kpi: true
+    dashboard: revenue-dashboard
+    alerts:
+      - threshold: 100
+        condition: less-than
+        severity: warning
+        message: "Order rate below threshold"
+```
+
+---
+
+## Example: Data Quality Metrics
+
+```yaml
+id: apm.data-quality-metrics.user-data
+name: "User Data Quality Metrics"
+type: data-quality-metrics
+properties:
+  entity: data_model.object-schema.user
+  metrics:
+    - name: completeness
+      type: gauge
+      description: "Percentage of non-null required fields"
+      target: 95%
+    - name: validity
+      type: gauge
+      description: "Percentage of records passing validation"
+      target: 99%
+    - name: uniqueness
+      type: gauge
+      description: "Percentage of unique email addresses"
+      target: 100%
+    - name: freshness
+      type: histogram
+      description: "Time since last update"
+      target: 24h
+```
+
+---
+
+## Pitfalls to Avoid
+
+- ❌ Not propagating trace context across services
+- ❌ High-cardinality attributes (e.g., unique IDs in tags)
+- ❌ Missing business metrics (only technical metrics)
+- ❌ Not setting SLOs/SLAs
+- ❌ Over-instrumentation (too many spans)
+- ❌ Missing cross-layer links to instrumented services

package/dist/integrations/github_copilot/skills/dr_12_testing_layer/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: LAYER_12_TESTING
+description: Expert knowledge for Testing Layer modeling in Documentation Robotics
+triggers:
+  [
+    "testing",
+    "test coverage",
+    "test case",
+    "input partition",
+    "ISP",
+    "test strategy",
+    "coverage model"
+  ]
+version: 0.8.1
+---
+
+# Testing Layer Skill
+
+**Layer Number:** 12
+**Specification:** Metadata Model Spec v0.8.1
+**Purpose:** Defines test coverage using ISP (Input Space Partitioning) Coverage Model, specifying coverage requirements, test cases, and input partitions.
+
+---
+
+## Layer Overview
+
+The Testing Layer captures **test coverage strategy**:
+
+- **COVERAGE MODELS** - Overall test coverage requirements
+- **COVERAGE TARGETS** - What needs testing (APIs, features, data)
+- **INPUT PARTITIONS** - Partition input space for systematic coverage
+- **TEST CASES** - Concrete test case sketches
+- **CONTEXT VARIATIONS** - Environmental and contextual variations
+- **COVERAGE GAPS** - Identified gaps in coverage
+
+This layer uses **ISP Coverage Model** (systematic input space partitioning).
+
+**Central Entity:** The **TestCoverageModel** is the core modeling unit.
+
+---
+
+## Entity Types
+
+> **CLI Introspection:** Run `dr schema types testing` for the authoritative, always-current list of node types.
+> Run `dr schema node <type-id>` for full attribute details on any type.
+
+### Core Testing Entities (17 entities)
+
+| Entity Type                 | Description                              |
+| --------------------------- | ---------------------------------------- |
+| **TestCoverageModel**       | Root coverage model for system/component |
+| **TestCoverageTarget**      | What needs testing (API, feature, data)  |
+| **InputSpacePartition**     | Partition of input space                 |
+| **PartitionValue**          | Value/range within partition             |
+| **InputPartitionSelection** | Selected partition values for coverage   |
+| **CoverageRequirement**     | Specific coverage requirement            |
+| **TestCaseSketch**          | High-level test case description         |
+| **OutcomeCategory**         | Expected outcome categories              |
+| **ContextVariation**        | Environmental/contextual variation       |
+| **EnvironmentFactor**       | Environment-specific factor              |
+| **PartitionDependency**     | Dependencies between partitions          |
+| **CoverageGap**             | Identified gap in coverage               |
+| **CoverageExclusion**       | Explicitly excluded coverage             |
+| **CoverageSummary**         | Summary of coverage status               |
+| **TargetCoverageSummary**   | Coverage summary for target              |
+| **TargetInputField**        | Input field for target                   |
+
+---
+
+## When to Use This Skill
+
+Activate when the user:
+
+- Mentions "testing", "test coverage", "test cases", "ISP"
+- Wants to define test strategy or coverage requirements
+- Asks about input partitioning or systematic testing
+- Needs to model test cases for APIs, features, or data
+- Wants to link testing to requirements or business goals
+
+---
+
+## Cross-Layer Relationships
+
+**Outgoing (Testing → Other Layers):**
+
+- `motivation.supports-goals` → Motivation Layer (quality goals)
+- `motivation.fulfills-requirements` → Motivation Layer (test requirements)
+- `business.covers-process` → Business Layer (process coverage)
+- `api.tests-operation` → API Layer (API endpoint testing)
+- `data.validates-schema` → Data Model Layer (data validation)
+- `ux.tests-view` → UX Layer (UI testing)
+
+**Incoming (Other Layers → Testing):**
+
+- Motivation Layer → Testing (requirements drive coverage)
+- API Layer → Testing (operations need test coverage)
+- Business Layer → Testing (processes need testing)
+
+---
+
+## Testing Best Practices
+
+1. **Systematic partitioning** - Use ISP to partition input space
+2. **Coverage criteria** - Define clear coverage criteria
+3. **Context variations** - Test across different contexts
+4. **Traceability** - Link tests to requirements and features
+5. **Gap analysis** - Identify and document coverage gaps
+6. **Exclusions** - Explicitly document what's not tested
+7. **Outcome categories** - Define expected outcomes clearly
+
+---
+
+## Common Commands
+
+```bash
+# Add coverage model
+dr add testing test-coverage-model --name "API Coverage Model"
+
+# Add coverage target
+dr add testing test-coverage-target --name "Login API Coverage"
+
+# Add test case sketch
+dr add testing test-case-sketch --name "Valid Login Test"
+
+# List coverage models
+dr list testing test-coverage-model
+
+# Validate testing layer
+dr validate --layer testing
+
+# Export coverage report
+dr export --layer testing --format markdown
+```
+
+---
+
+## Example: Login API Coverage Model
+
+```yaml
+id: testing.coverage-model.login-api
+name: "Login API Coverage Model"
+type: test-coverage-model
+properties:
+  targets:
+    - testing.target.login-endpoint
+  coverageCriteria: each-choice
+  contextVariations:
+    - browser: [Chrome, Firefox, Safari]
+    - network: [high-speed, low-speed, offline]
+    - device: [desktop, mobile, tablet]
+  motivation:
+    supports-goals:
+      - motivation.goal.quality-assurance
+    fulfills-requirements:
+      - motivation.requirement.comprehensive-testing
+```
+
+---
+
+## Example: Login Test Coverage Target
+
+```yaml
+id: testing.target.login-endpoint
+name: "Login Endpoint Coverage"
+type: test-coverage-target
+properties:
+  targetRef: api.operation.login
+  inputFields:
+    - name: email
+      partitions:
+        - valid-email: [user@example.com]
+        - invalid-format: [notanemail, @example.com]
+        - missing: [null, empty]
+    - name: password
+      partitions:
+        - valid-password: [StrongPass123!]
+        - weak-password: [123, abc]
+        - missing: [null, empty]
+        - too-long: [1000-char-string]
+  outcomeCategories:
+    - success: 200 OK with auth token
+    - invalid-credentials: 401 Unauthorized
+    - validation-error: 400 Bad Request
+    - rate-limited: 429 Too Many Requests
+  testCases:
+    - testing.test-case.valid-login
+    - testing.test-case.invalid-email
+    - testing.test-case.invalid-password
+    - testing.test-case.missing-credentials
+```
+
+---
+
+## Example: Test Case Sketch
+
+```yaml
+id: testing.test-case.valid-login
+name: "Valid Login Test Case"
+type: test-case-sketch
+properties:
+  target: testing.target.login-endpoint
+  description: "Test successful login with valid credentials"
+  inputSelection:
+    email: valid-email
+    password: valid-password
+  contextSelection:
+    browser: Chrome
+    network: high-speed
+    device: desktop
+  expectedOutcome: success
+  expectedResponse:
+    status: 200
+    body:
+      token: JWT token present
+      user: User object with id and email
+  motivation:
+    supports-goals:
+      - motivation.goal.secure-authentication
+```
+
+---
+
+## Pitfalls to Avoid
+
+- ❌ Ad-hoc testing without systematic partitioning
+- ❌ Missing context variations (only testing happy path)
+- ❌ Not documenting coverage gaps
+- ❌ No traceability to requirements
+- ❌ Missing cross-layer links to tested elements
+- ❌ Incomplete outcome categories