daneuchar

### Scenario: View collapsed node details
```gherkin
Given the application is loaded
And all nodes are in collapsed state
When I look at a collapsed data product node
Then I should see the data product name
And I should see the count of input ports
And I should see the count of output ports
And I should see an expand button with a chevron icon
And I should see connection handles on left and right sides

daneuchar

mutation CreateDataContract($input: DataContractInput!) {
  createDataContract(input: $input) {
    id
    contractId
    version
    isLatest
    spec {
      spec {
        version
        odcsVersion

daneuchar

graph TD
    Start((Large Feature Goal, Story with acceptance )) --> Decomp[Decompose into Sub-Tasks]
    
    subgraph IterativeCycle [The Dev-Review Loop ]
        Decomp --> Branch[Create Feature-Sub-Branch]
        Branch --> Coding[Implement Small Logic Chunk]
        Coding --> LocalTest[Local Testing / Unit Tests]
        LocalTest --> PR[IDE AI assited review]
        PR --> Review[Human Peer Review & Feedback]
        Review -- Changes Needed --> Coding

daneuchar

flowchart TD
    A[📄 Document Modules] --> B[🤖 GitHub Copilot]
    B --> |Uses docs as instructions| C[⚙️ Create New Feature]
    C --> D{Feature Complete?}
    D --> |No| C
    D --> |Yes| E[📋 Review Git Diff]
    E --> F[✏️ Update Documentation]
    F --> |Next feature| A

    style A fill:#4a90d9,stroke:#2d5a8a,color:#fff

daneuchar

# ADR-001: Feature Development Workflow

| Status | Date | Author |
|--------|------|--------|
| Accepted | 2026-01-22 | Engineering Team |

## Context

As our team scales, we need a consistent, repeatable process for developing features that ensures code quality while maintaining development velocity. Without a standardized workflow, we risk inconsistent quality, integration issues, and unclear handoff points between team members.

daneuchar

# Document Azure Function API Endpoints as Versioned OpenAPI Specs

## Purpose

Scan the entire TypeScript Azure Functions codebase, discover all HTTP-triggered
functions, extract their API metadata (route, method, request/response schemas,
auth level, parameters), group them by API version, and generate one OpenAPI 3.0
YAML file per version.

## Output Convention

daneuchar

---
name: graphql-architect
description: "Use this agent when designing or evolving GraphQL schemas across microservices, implementing federation architectures, or optimizing query performance in distributed graphs."
tools: Read, Write, Edit, Bash, Glob, Grep
model: opus
---

You are a senior GraphQL architect specializing in schema design and distributed graph
architectures. You have deep expertise in Apollo Federation 2.5+, GraphQL subscriptions,
query performance, and clean, maintainable server-side code. Your primary focus is

daneuchar

# Data Mesh Platform — Directory Structure
# Architecture : Hexagonal (Ports & Adapters) + CQRS (separate read/write paths)
# Pattern      : Read path → Redis projections (low latency, no DB hits)
#                Write path → Command → Use Case → Domain → Event → EventHub
# Stack        : TypeScript · Apollo Federation · Azure EventHub · Kafka · Redis · PostgreSQL

.
├── apps/
│   │
│   ├── gateway/                                        # Apollo Router — entry point for all GraphQL traffic

daneuchar

# Clean Code Rules
# Stack: TypeScript · Node.js · Apollo Federation · GraphQL · Kafka · EventHub
# These rules are non-negotiable across every package and subgraph in the monorepo.

---

## 1. SIZE LIMITS — hard ceilings, not guidelines

| Unit                  | Max Lines | Rationale                                              |
|-----------------------|-----------|--------------------------------------------------------|

daneuchar

# Multi-Service Flow Orchestration Pattern

**Date:** 2026-03-16
**Status:** Approved

## Overview

Design for a **reusable multi-service API orchestration pattern** (the "Flow" layer) within the existing BDD test framework. A flow chains multiple services where each stage's output feeds into the next.

The Data Product Registration flow below is the **first implementation** of this pattern, serving as the reference for all future multi-service flows.