🗂️ Backend Library Blueprints¶

🧭 Introduction to Backend Library Blueprints¶

📘 What Is a Backend Library Blueprint?¶

A Backend Library Blueprint defines a reusable, testable, DI-friendly .NET class library that can be:

Injected into microservices or platforms
Published as a NuGet artifact
Composed with other libraries or services
Embedded with cross-cutting capabilities (e.g., logging, validation, observability)

In the ConnectSoft AI Software Factory, this blueprint standardizes the creation, structure, and regeneration of libraries that are not applications themselves, but pluggable backend components.

🧱 What It Enables¶

Capability	Description
🧩 Reusability	Build once, reuse across 100s of microservices
🤖 Agent Generation	Created and extended by agents during service or platform generation
📦 Artifactization	Packages libraries into NuGet feeds for sharing
🧪 Testability	Includes test project, coverage thresholds, and test blueprint
🧠 Prompt Injection	Blueprint metadata is used in prompt construction (e.g., usage samples, DI help)

🧠 Factory Use Cases¶

Infrastructure Libraries (e.g., ConnectSoft.Extensions.Http, ConnectSoft.Extensions.Logging)
Shared Abstractions (IAuthorizationClient, IUserContextProvider)
Connectors/Adapters (ISegmentClient, IChatGptResponseParser)
Decorators & Handlers for patterns like Retry, Resilience, Tracing

🔧 Blueprint Output Examples¶

Artifact	Description
`ConnectSoft.LibraryTemplate.csproj`	.NET library project
`src/Options/MyLibraryOptions.cs`	Options-bound config class
`src/DI/ServiceCollectionExtensions.cs`	DI registration extension
`tests/MyLibrary.Tests.csproj`	MSTest-based unit test project
`azure-pipelines.yml`	CI for build + test + pack
`README.md`	Human-facing doc rendered from blueprint

🎯 Blueprint Role in the Platform¶

graph TD
    BackendLibraryBlueprint --> LibraryProject
    BackendLibraryBlueprint --> Tests
    BackendLibraryBlueprint --> Pipeline
    BackendLibraryBlueprint --> NuGetPackage
    BackendLibraryBlueprint --> PromptContexts
    BackendLibraryBlueprint --> Documentation

Hold "Alt" / "Option" to enable pan & zoom

This blueprint serves as the single source of truth for both generation and regeneration of backend libraries.

🧠 Agents That Use This Blueprint¶

Agent	Usage
🛠️ Library Builder Agent	Generates .csproj, DI classes, and options scaffold
🧪 Test Generator Agent	Builds MSTest structure and coverage expectations
🧬 CI/CD Pipeline Agent	Creates `azure-pipelines.yml`, build/test/package flow
📘 Documentation Agent	Populates `README.md` and example usage
🧠 Prompt Injection Agent	Uses metadata for downstream LLM prompts

✅ Summary¶

A backend library blueprint encodes metadata and structure for creating portable, injectable, well-tested .NET libraries
It supports test-first, documentation-rich, pipeline-integrated libraries
It is fully compatible with ConnectSoft’s agentic generation model, NuGet pipelines, and multi-service platforms

🧱 Blueprint Structure Overview¶

This section defines the complete structure of a Backend Library Blueprint and maps each component to its purpose in the AI Software Factory. While the blueprint results in a .NET Core project, the structure also includes metadata, automation hooks, and code generation logic.

📂 Core Structure of the Blueprint¶

blueprints/
└── libraries/
    └── connectsoft.http-auth/
        ├── library-blueprint.yaml
        ├── options.yaml
        ├── features.md
        ├── use-cases.md
        ├── overview.md
        └── runbook.md

📘 Key Blueprint Files Explained¶

File	Purpose
`library-blueprint.yaml`	Main metadata definition (name, namespace, options, DI, logging, etc.)
`options.yaml`	Options definition (strong-typed config bound to `IOptions<T>`)
`features.md`	Human-readable description of available cross-cutting features
`use-cases.md`	Lists integrations and recommended usages
`overview.md`	Summary of what the library does and where it fits in platform
`runbook.md`	Operational instructions, diagnostics, lifecycle handling

🧱 Blueprint vs Output Structure¶

Blueprint File	Produces →	Output Artifact
`library-blueprint.yaml`	🛠️ `.csproj`, namespaces, folder layout
`options.yaml`	📦 `MyLibraryOptions.cs`, binding, validation
`features.md`	📘 Rendered into `README.md` and doc site
`runbook.md`	📊 Included in `/docs/` folder of repo and NuGet
`overview.md`	📘 Documentation site page and metadata enrichment
`use-cases.md`	🧠 Prompt context for example generation or integration docs

🧩 Output Directories (After Execution)¶

src/
├── ConnectSoft.MyLibrary/
│   ├── MyLibraryOptions.cs
│   ├── MyService.cs
│   └── ServiceCollectionExtensions.cs

tests/
└── ConnectSoft.MyLibrary.Tests/
    └── MyLibraryTests.cs

docs/
├── runbook.md
├── overview.md
├── README.md (rendered)

📦 References to Other Artifacts¶

Unlike microservices, backend library projects reference other services or runtime dependencies by:

📦 NuGet packages (defined in blueprint)
📦 Containerized external services (optional)
🧩 DSL or contract definitions used for integration

This allows compatibility with Aspire-style composability without requiring runtime orchestration logic inside the blueprint.

📘 Example: Minimal `library-blueprint.yaml`¶

id: connectsoft.extensions.http
name: ConnectSoft.Extensions.Http
namespace: ConnectSoft.Extensions.Http
description: OAuth2-based authenticated HttpClient handler for outbound APIs

di: true
logging: true
options:
  file: options.yaml
targets:
  - net8.0
  - net9.0
ci:
  pipeline: azure
  publish: true
  feed: connectsoft-artifacts

✅ Summary¶

A backend library blueprint includes both declarative metadata and execution outputs
It defines structure, capabilities, DI logic, config options, and documentation
It is used by multiple factory agents and results in NuGet-publishable packages
It supports reference to external dependencies and is composable at platform-level

🧭 Blueprint DSL & CLI Parameters¶

This section defines how Domain-Specific Language (DSL) fragments and CLI parameters are integrated into the backend library blueprint. These inputs guide generation behavior, control feature toggles, and define conditional output logic.

🧩 CLI Parameters → DSL Integration¶

The library-blueprint.yaml blueprint can accept CLI parameters, especially during initial generation via dotnet new, ai-factory, or agent skill wrappers. These parameters act as switches that:

Control presence of optional code (e.g., DI, logging, options binding)
Influence DSL references (e.g., shared contracts, REST/GraphQL clients)
Modify generation decisions (e.g., skip tests, mark experimental)

🔧 CLI Parameters Examples (mapped to DSL fields)¶

CLI Parameter	Blueprint Effect	DSL Impact
`--useDI`	Adds `ServiceCollectionExtensions.cs`	Activates `di = true`
`--useOptions`	Generates options class and validation	Loads `options.yaml`
`--useLogging`	Injects `ILogger<>` into core classes	Sets `logging = true`
`--noTest`	Skips test project creation	`tests.enabled = false`
`--contracts shared`	References `ConnectSoft.Contracts.Shared` DSLs	Registers shared DSL in prompt scope

🧬 Blueprint Snippet With CLI Parameters Reflected¶

di: true
logging: true
options:
  file: options.yaml
tests:
  enabled: true
dslRefs:
  - contracts/shared/http-client-contract.yaml
  - observability/span-definitions.yaml

This is what an enriched blueprint looks like after CLI-driven generation.

🧠 DSL Purpose and Reusability¶

DSLs are injected into the blueprint to:

Provide entity or contract definitions
Declare observability schema (e.g., span names, metrics)
Reference common validation rules (e.g., string policies, enums)
Enable agent prompt context alignment

These DSLs are shared across the platform and referenced semantically — they are not copied but linked into prompt memory and build flow.

💡 Prompt Template Impact¶

Agents (e.g., TestAgent, CodeExampleAgent, DocWriterAgent) use DSLs referenced in the blueprint to populate prompt contexts:

{
  "promptContext": {
    "libraryId": "connectsoft.extensions.http",
    "supportsDI": true,
    "usesOptions": true,
    "linkedDSLs": [
      "contracts/shared/http-client-contract.yaml",
      "observability/span-definitions.yaml"
    ]
  }
}

🛠️ CLI Usage Example¶

ai-factory new library connectsoft.extensions.http \
  --useDI --useOptions --useLogging \
  --contracts shared \
  --dsl observability/span-definitions.yaml

This command would generate the full blueprint, source code, test project, and docs in a few seconds using the agentic factory runtime.

✅ Summary¶

CLI parameters drive initial blueprint enrichment
DSLs inject semantic context for generation, prompt usage, and validation
Agents use this information to produce aligned, consistent, traceable backend libraries
CLI+DSL integration ensures repeatable scaffolding and automated reasoning

🧪 Test and CI/CD Metadata¶

This section focuses on how the backend library blueprint encodes metadata for automated testing, test coverage enforcement, and CI/CD integration. These definitions ensure the library is not just generated but also verifiably testable and ready for packaging and publishing in an autonomous pipeline.

🧪 Test Metadata in the Blueprint¶

The blueprint enables agents to define test behavior and structure via:

tests:
  enabled: true
  framework: MSTest
  coverage:
    minThreshold: 80
    enforce: true
  integrationTests: false
  testAgent: ai-test-agent-v1

This metadata is read by the Test Generator Agent, CI Pipeline Agent, and Coverage Validator Agent to enforce quality standards.

🧪 Output of the Test Blueprint¶

Output File	Purpose
`tests/ConnectSoft.MyLibrary.Tests.csproj`	Project file for MSTest
`MyLibraryTests.cs`	Initial test class
`coverage.runsettings`	Threshold rules
`test-blueprint.trace.yaml`	Traceable semantic plan for agents

🧪 Example Test Scaffolding Output¶

[TestClass]
public class MyLibraryTests
{
    [TestMethod]
    public void HttpClient_IsAuthenticated()
    {
        var client = Factory.CreateHttpClient();
        var response = client.GetAsync("/ping").Result;
        Assert.AreEqual(HttpStatusCode.OK, response.StatusCode);
    }
}

Agents can use the blueprint metadata to decide what core behavior must be tested — including DI bootstraps, options validation, and feature toggles.

🔁 Regeneration Support¶

If tests are deleted, outdated, or misaligned, the Test Validator Agent triggers a TestDriftDetected event and suggests regeneration:

testValidation:
  status: drifted
  missingTests:
    - MyLibraryOptionsValidationTests.cs
    - LoggingBehaviorTests.cs

⚙️ CI/CD Metadata¶

CI/CD behavior is also part of the blueprint:

ci:
  pipeline: azure
  template: library-ci.yml
  publish: true
  feed: connectsoft-artifacts
  runTests: true
  collectCoverage: true

Used by the Pipeline Generator Agent and DevOps Orchestrator Agent, this controls:

CI pipeline generation
Packaging tasks (dotnet pack)
Artifact feeds
Gate controls (test + coverage)

🔁 Test and Coverage Flow¶

graph TD
    LibraryBlueprint --> TestPlan
    TestPlan --> MSTestProject
    MSTestProject --> CoverageRules
    TestPlan --> CI_Pipeline
    CI_Pipeline --> AzureArtifacts

Hold "Alt" / "Option" to enable pan & zoom

🧠 Agent Usage¶

Agent	Role
Test Generator Agent	Generates MSTest projects and files
CI/CD Pipeline Agent	Injects test/coverage into `azure-pipelines.yml`
Test Drift Validator	Detects missing, misaligned, or failed test coverage
Doc Generator Agent	Lists test coverage % in README or doc site

✅ Summary¶

Test logic is part of the blueprint and enforces:
Coverage thresholds
MSTest/BDD styles
Drift detection
CI/CD instructions are embedded for:
Pack + publish
Run tests and collect results
Testing is a first-class concern, not an afterthought

🗂️ Project Layout Convention¶

This section defines the standard folder and file layout generated from a backend library blueprint. It ensures consistent structure across ConnectSoft libraries, enabling agents, developers, CI systems, and documentation generators to operate reliably across thousands of generated libraries.

📁 Standard Folder Structure¶

📁 ConnectSoft.MyLibrary/
├── 📂 src/
│   └── 📂 ConnectSoft.MyLibrary/
│       ├── MyLibraryOptions.cs
│       ├── MyLibraryService.cs
│       ├── ServiceCollectionExtensions.cs
│       └── TracingConstants.cs
├── 📂 tests/
│   └── 📂 ConnectSoft.MyLibrary.Tests/
│       └── MyLibraryTests.cs
├── 📂 docs/
│   ├── overview.md
│   ├── features.md
│   ├── runbook.md
│   └── use-cases.md
├── 📂 blueprints/
│   └── library-blueprint.yaml
├── README.md
├── azure-pipelines.yml
└── Directory.Build.props

📦 Project Structure Expectations¶

Component	Purpose
`src/ConnectSoft.MyLibrary/`	Main library code (options, DI hooks, logic)
`tests/ConnectSoft.MyLibrary.Tests/`	MSTest project with mirrored naming
`docs/`	Extended documentation: runbook, features, use cases
`blueprints/`	The YAML blueprint and supporting generation metadata
`README.md`	AI-generated summary and usage example
`azure-pipelines.yml`	CI/CD pipeline definition
`Directory.Build.props`	Centralizes versioning, analyzers, SDKs

🧩 Blueprint Enforcement¶

Agents validate layout against the blueprint. Deviations trigger:

LayoutDriftDetected
Auto-healing suggestions
README and doc regeneration

💡 Naming Convention Rules¶

Type	Convention
Library ID	`connectsoft.extensions.<area>`
Namespace	`ConnectSoft.Extensions.<Area>`
Test Project	`.Tests` suffix, same namespace
NuGet Package ID	`ConnectSoft.Extensions.<Area>`

🧪 Naming Examples¶

Library Name	NuGet ID	Namespace
`connectsoft.extensions.http`	`ConnectSoft.Extensions.Http`	`ConnectSoft.Extensions.Http`
`connectsoft.adapters.segment`	`ConnectSoft.Adapters.Segment`	`ConnectSoft.Adapters.Segment`

🧠 AI Prompt Context Injection¶

Prompt agents (e.g., example generators) are fed file layout from the blueprint:

{
  "structure": {
    "src": "ConnectSoft.MyLibrary",
    "tests": "ConnectSoft.MyLibrary.Tests",
    "docs": ["overview.md", "runbook.md"]
  },
  "di": true,
  "options": true,
  "hasTests": true
}

This enables prompt agents to suggest accurate file paths, function calls, and examples.

🧠 Agents Using Layout¶

Agent	Usage
Doc Generator Agent	Writes docs to `/docs/`
Test Generator Agent	Places tests into `/tests/` with matching naming
Pipeline Generator	Links paths into pipeline for test, pack
Code Drift Agent	Detects structural issues across solutions

✅ Summary¶

The project layout is standardized to support:
Composability
Observability
CI/CD consistency
Prompt enrichment
Agents rely on the structure for generation, regeneration, and validation
Naming and layout are enforced through the blueprint to maintain quality at scale

🧩 Code Scaffolding and Options Binding¶

This section details how the backend library blueprint supports automatic scaffolding of options-bound configuration classes, including:

Strongly-typed Options classes
Automatic binding to IConfiguration
DI integration via IOptions<T>
Validation logic with DataAnnotations
Optional default values and descriptions

🧾 `options.yaml`: Declarative Configuration Definition¶

This file defines the structure, types, and rules for options classes in the library. Example:

className: HttpAuthOptions
sectionName: HttpAuth
properties:
  - name: BaseUrl
    type: string
    required: true
    description: Base URI for outbound API requests

  - name: TokenEndpoint
    type: string
    required: true

  - name: RetryCount
    type: int
    default: 3
    description: Max number of retry attempts

🧱 Generated Output – Options Class¶

public class HttpAuthOptions
{
    [Required]
    public string BaseUrl { get; set; }

    [Required]
    public string TokenEndpoint { get; set; }

    public int RetryCount { get; set; } = 3;
}

🧪 Validation Hook in DI¶

services.AddOptions<HttpAuthOptions>()
        .Bind(configuration.GetSection("HttpAuth"))
        .ValidateDataAnnotations()
        .ValidateOnStart();

This is injected automatically if options.yaml is present and useOptions: true is set in library-blueprint.yaml.

📘 Blueprint Fields That Trigger Options Scaffolding¶

options:
  file: options.yaml
  sectionPrefix: HttpAuth
  validation: true

These fields are read by the Scaffolding Agent and DI Agent to:

Generate Options class
Register validation
Set section name prefix
Enable documentation of config schema

📚 Agentic Documentation From Options¶

## Configuration

```json
"HttpAuth": {
  "BaseUrl": "https://api.partner.com/",
  "TokenEndpoint": "/oauth2/token",
  "RetryCount": 3
}

This block is inserted by the **Documentation Agent** in the `README.md` and `runbook.md`.

---

### 🧠 AI Prompt Enrichment with Options

```json
{
  "config": {
    "HttpAuth": {
      "BaseUrl": "<required>",
      "TokenEndpoint": "<required>",
      "RetryCount": 3
    }
  }
}

Used by code example and sample test generation agents to suggest proper usage.

🧠 Agent Roles for Options¶

Agent	Purpose
Options Scaffolder	Generates the `.cs` file from `options.yaml`
DI Agent	Registers it in the container with validation
Doc Generator	Adds config JSON to README and runbook
Prompt Agent	Adds config structure to prompt memory
Test Agent	Validates fallback/default behavior

✅ Summary¶

options.yaml enables declarative config → C# class scaffolding
Supports validation, binding, testing, and doc generation
Ensures all libraries are configurable, safe, and observable
Enables consistent patterns across 1000+ generated libraries

♻️ DI and Logging Integration Blueprint¶

This section describes how the backend library blueprint supports automatic Dependency Injection (DI) and ILogger integration, making each library:

Composable via IServiceCollection
Traceable and observable via structured logs
Consistent with platform-wide registration patterns

🧰 DI Integration Blueprint Fields¶

di: true
logging: true

When enabled, these flags trigger agents to scaffold:

ServiceCollectionExtensions.cs for DI registration
Constructor injection of ILogger<T>
Lifecycle-aware logging in key components

📦 DI Scaffolding Output¶

📄 ServiceCollectionExtensions.cs

public static class MyLibraryServiceCollectionExtensions
{
    public static IServiceCollection AddMyLibrary(this IServiceCollection services, IConfiguration config)
    {
        services.Configure<MyLibraryOptions>(config.GetSection("MyLibrary"));
        services.AddSingleton<IMyLibraryService, MyLibraryService>();
        return services;
    }
}

Automatically wired from the blueprint and options metadata.

🔍 Logging Scaffolding Output¶

📄 MyLibraryService.cs

public class MyLibraryService : IMyLibraryService
{
    private readonly ILogger<MyLibraryService> logger;

    public MyLibraryService(ILogger<MyLibraryService> logger)
    {
        this.logger = logger;
    }

    public void Execute()
    {
        logger.LogInformation("Executing MyLibraryService");
    }
}

Injected automatically when logging: true is defined.

🧠 AI Prompt Enrichment¶

Blueprint metadata is injected into prompt context:

{
  "di": true,
  "logging": true,
  "options": true,
  "registerMethod": "AddMyLibrary",
  "namespace": "ConnectSoft.Extensions.Http"
}

This allows the prompt engine to generate accurate example usage, test mocking setups, and registration snippets.

🧪 Test Validation of DI¶

The Test Agent validates registration behavior:

[TestMethod]
public void Service_IsRegistered()
{
    var services = new ServiceCollection();
    services.AddMyLibrary(configuration);
    var provider = services.BuildServiceProvider();
    var svc = provider.GetService<IMyLibraryService>();
    Assert.IsNotNull(svc);
}

🧩 Blueprint to Runtime Flow¶

graph TD
    Blueprint["library-blueprint.yaml"]
    Blueprint --> ServiceExtensions["ServiceCollectionExtensions.cs"]
    Blueprint --> LoggerScaffold["ILogger<T> injection"]
    ServiceExtensions --> DIContainer
    LoggerScaffold --> DIContainer

Hold "Alt" / "Option" to enable pan & zoom

🧠 Agent Roles¶

Agent	Role
DI Scaffolder Agent	Creates extension methods and DI hooks
Logging Agent	Injects ILogger + trace spans
Doc Generator Agent	Includes DI setup examples
Test Agent	Asserts DI registration
CI/CD Pipeline Agent	Ensures DI and logging behavior are covered in validation gates

✅ Summary¶

di: true and logging: true in the blueprint trigger DI + logging integration
Ensures libraries are:
Easily injectable
Traceable with logs
Configurable via options
Aligns with ConnectSoft platform conventions and promotes plug-and-play reuse

🎯 Multi-TFM and Targeting Metadata¶

This section defines how backend library blueprints express target framework compatibility via multi-TFM (Target Framework Moniker) metadata. This enables the same library to work across .NET 8, .NET 9, and beyond — a critical capability for composability and longevity in a multi-solution ecosystem.

📘 Targeting Field in Blueprint¶

targets:
  - net8.0
  - net9.0
  - netstandard2.1

These values are injected directly into the generated .csproj file and respected by all downstream tools (NuGet, MSBuild, test runners, etc.).

🧱 Output: Multi-TFM `.csproj`¶

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net8.0;net9.0;netstandard2.1</TargetFrameworks>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Blueprint agents always generate TargetFrameworks (plural) for long-term forward compatibility, even if only one version is used initially.

🧪 TFM Testing Matrix¶

Generated CI pipelines test against all listed TFMs:

strategy:
  matrix:
    net8:
      framework: 'net8.0'
    net9:
      framework: 'net9.0'
    netstandard:
      framework: 'netstandard2.1'

This matrix is injected into azure-pipelines.yml by the CI/CD Pipeline Agent.

🧬 Compatibility Enforcement¶

Blueprints may optionally enforce cross-TFM constraints:

tfmConstraints:
  forbidPreprocessorDirectives: true
  forbidReflectionForTFMDetection: true

These rules guide the Analyzer Agent or Test Drift Validator to reject brittle, TFM-specific hacks.

📦 NuGet Packaging Impact¶

When publishing, the resulting .nupkg includes assemblies for each target:

lib/
├── net8.0/
│   └── ConnectSoft.MyLibrary.dll
├── net9.0/
│   └── ConnectSoft.MyLibrary.dll
├── netstandard2.1/
│   └── ConnectSoft.MyLibrary.dll

This guarantees consumption across different microservices and platforms using varying .NET versions.

🧠 Prompt Context Enrichment¶

Agents working with the blueprint add TFM details to their prompt payload:

{
  "targets": ["net8.0", "net9.0", "netstandard2.1"],
  "defaultFramework": "net8.0"
}

This enables prompt-based agents (e.g., Test Generator, Example Generator) to align examples with the expected runtime.

🧠 Agents Using TFM Metadata¶

Agent	Usage
CI/CD Pipeline Agent	Adds build/test matrix
NuGet Publisher Agent	Publishes multi-TFM package
Analyzer Agent	Detects anti-patterns like `#if NET8_0`
Prompt Agents	Renders framework-specific usage docs
Compatibility Checker	Verifies library works in platform-wide service graphs

✅ Summary¶

TFM metadata enables cross-version compatibility and NuGet-wide reuse
Ensures generated libraries are future-proof and safe to integrate
Blueprint expresses:
Supported frameworks
Optional constraints
CI build/test matrix
Promotes consistency across all ConnectSoft platform microservices

🧪 Test Project Blueprint Structure¶

This section defines the scaffolded test project layout, structure, naming conventions, and validation hooks associated with every backend library blueprint. The blueprint ensures that testing is enforced, discoverable, and extendable — across both functional and structural levels.

🧱 Standard Test Project Output¶

tests/
└── ConnectSoft.MyLibrary.Tests/
    ├── ConnectSoft.MyLibrary.Tests.csproj
    ├── MyLibraryTests.cs
    ├── TestBase.cs
    └── TestHelpers/
        └── FakeHttpClientFactory.cs

All tests follow the MSTest standard unless overridden, and are generated alongside the library source to guarantee coverage expectations.

📘 Blueprint Test Metadata¶

tests:
  enabled: true
  framework: MSTest
  structure:
    baseClass: TestBase
    useHelpersFolder: true
  naming:
    projectSuffix: .Tests
    classSuffix: Tests

Enables test code generation, test file layout, and CI pipeline alignment.

🧪 Scaffolding Example: `MyLibraryTests.cs`¶

[TestClass]
public class MyLibraryTests : TestBase
{
    [TestMethod]
    public void Should_Initialize_Service_With_Defaults()
    {
        var service = CreateService();
        Assert.IsNotNull(service);
    }
}

🧰 Shared Helpers in `/TestHelpers/`¶

The blueprint supports reusable test helpers, mocks, and factories such as:

FakeHttpClientFactory
InMemoryConfigBuilder
SpanTestHelper
LoggerSinkInterceptor

Generated conditionally when useHelpersFolder: true.

🧠 CI Integration Hooks¶

Test projects are auto-included in CI:

steps:
  - task: DotNetCoreCLI@2
    inputs:
      command: 'test'
      projects: '**/*.Tests.csproj'
      arguments: '--collect:"XPlat Code Coverage"'

CI is smart enough to detect test project structure based on blueprint metadata.

📦 Packaging Impact¶

Test projects are excluded from .nupkg artifacts but are validated pre-publish.

Agents fail the build if:

Tests are missing
Coverage thresholds are not met
Test structure deviates from blueprint

🧠 AI Prompt Context Example¶

{
  "test": {
    "enabled": true,
    "framework": "MSTest",
    "testHelpers": ["FakeHttpClientFactory"],
    "baseClass": "TestBase"
  }
}

Prompt agents generate test snippets aligned to this structure, increasing explainability and traceability.

🧠 Agents Using Test Blueprint Structure¶

Agent	Purpose
Test Generator Agent	Builds initial `*.Tests.cs` files
Test Drift Agent	Detects deviation from structure
CI/CD Agent	Includes test projects in the pipeline
Coverage Validator	Enforces required tests/thresholds
Doc Generator	Injects test coverage table in `README.md`

✅ Summary¶

Test structure is blueprint-driven, scaffolded, and enforced
Results in discoverable MSTest projects with helpers and standards
Enables agents to:
Write
Validate
Regenerate
Document tests
Keeps quality consistent across thousands of generated libraries

🔧 Cross-Cutting Concerns Metadata¶

This section defines how the backend library blueprint expresses standardized cross-cutting capabilities that agents can scaffold, inject, validate, or disable. These concern types include logging, diagnostics, configuration, caching, observability, and exception handling.

🎯 Why It Matters¶

Cross-cutting concerns ensure:

🔁 Reusability across services and platforms
🔍 Observability and debuggability
🧪 Testability of non-functional behaviors
🧩 Plug-and-play compliance with platform standards

🧩 Blueprint Fields for Cross-Cutting Concerns¶

crossCutting:
  logging: true
  diagnostics: true
  configuration: true
  caching: false
  exceptionHandling: true
  observability:
    spans: true
    metrics: false

Each boolean or structured toggle triggers corresponding output or prompt behavior.

🔍 Concern-to-Agent Mapping¶

Concern	Triggers
`logging`	`ILogger<T>` injection, Serilog setup
`diagnostics`	Debug spans, headers, enriched error logs
`configuration`	Binds to `IOptions<T>`, validation
`caching`	Adds `IMemoryCache` with scoped wrapper
`exceptionHandling`	Try/catch blocks, safe wrappers, telemetry
`observability.spans`	Creates span start/stop wrappers
`observability.metrics`	Adds counter/timer infrastructure

🛠️ Sample Injected Behavior¶

MyLibraryService.cs with exception and span handling

public void Execute()
{
    using var span = tracer.StartSpan("myLibrary.execute");
    try
    {
        // core logic
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Failed to execute MyLibraryService");
        throw;
    }
}

This output is driven entirely by blueprint concern flags.

🔗 Relationship to Prompt Context¶

Prompt agents generate better examples, tests, and diagnostics when cross-cutting metadata is present:

{
  "crossCutting": {
    "logging": true,
    "exceptionHandling": true,
    "observability": {
      "spans": true,
      "metrics": false
    }
  }
}

🧠 Agents That Use These Fields¶

Agent	Behavior
Code Generator Agent	Injects decorators, wrappers
Test Generator Agent	Adds mocks for logs/metrics
Observability Agent	Configures span/metric hooks
Docs Agent	Explains how cross-cutting is handled
Drift Detector Agent	Flags if a concern is configured but not implemented

📚 Documentation Snippet (README.md)¶

## 🔧 Cross-Cutting Capabilities

This library includes:

- ✅ Structured logging (`ILogger<>`)
- ✅ Exception tracing with `try/catch + span`
- ✅ Configuration via `IOptions<>`
- 🚫 Caching (disabled by blueprint)
- ✅ Span-based observability for key methods

✅ Summary¶

Cross-cutting concerns are first-class in blueprint metadata
Used across agents for generation, validation, and documentation
Ensures platform-wide behaviors like logging and observability are consistently applied
Makes non-functional capabilities explicit, testable, and regenerable

📘 Documentation Block¶

This section defines how the backend library blueprint enables automated, agent-generated documentation, including:

Human-readable README.md
Platform docs: overview.md, features.md, runbook.md, use-cases.md
Semantic markdown injected from blueprint metadata
Continuous regeneration support

📂 Documentation Artifacts¶

docs/
├── overview.md
├── features.md
├── runbook.md
├── use-cases.md
README.md

All of these are generated from the blueprint and linked DSLs, not manually written.

📘 Blueprint Documentation Fields¶

documentation:
  enabled: true
  files:
    - overview.md
    - runbook.md
    - features.md
    - use-cases.md
  readme: true
  changelog: auto

These fields control what docs are generated and how often they are refreshed.

📄 Example: `README.md` Auto-Generated¶

# ConnectSoft.Extensions.Http

An authenticated HTTP client handler with OAuth2 and token caching support.
Supports configuration via `HttpAuthOptions`, DI integration, logging, and observability.

## 🔧 Usage

```csharp
services.AddHttpClient("partner-api")
    .AddOAuth2Handler(configuration.GetSection("HttpAuth"));

📦 Configuration¶

"HttpAuth": {
  "BaseUrl": "https://api.partner.com/",
  "TokenEndpoint": "/oauth/token"
}

🧪 Tests & Quality¶

✅ 14 unit tests (MSTest)
✅ 93% code coverage
✅ Validated config + DI + retries

---

### 📊 Features: `features.md`

Derived from blueprint `crossCutting`, `options.yaml`, and agent annotations:

```markdown
## Features

- ✅ OAuth2 token exchange
- ✅ Retry logic for transient failures
- ✅ ILogger-compatible logging
- ✅ Custom `IHttpClientFactory` integration

🧭 Runbook: `runbook.md`¶

Generated from blueprint metadata + operational intent:

## Runtime Behavior

- Uses memory cache for tokens
- On startup, validates configuration
- Logs all HTTP failures with trace IDs

## Diagnostics

- `X-Trace-ID` is included in all outbound requests
- Observe span: `outbound.http.token_acquisition`

🔁 Regeneration Hooks¶

If docs drift from blueprint or DSL, the Documentation Agent emits:

docValidation:
  status: out-of-sync
  recommendedRegeneration:
    - README.md
    - features.md

🧠 Prompt Context Enrichment¶

Used to insert docs directly into prompt scaffolds for downstream agents:

{
  "documentation": {
    "overview": "OAuth2-authenticated HTTP handler",
    "features": ["Retry", "ILogger", "Token Caching"]
  }
}

🧠 Agents Involved¶

Agent	Role
Documentation Agent	Generates all markdown artifacts
Prompt Agent	Loads docs into context window
Test Generator Agent	Updates testing section in `README.md`
Changelog Agent	Creates or updates `CHANGELOG.md`
Runbook Validator	Ensures operational detail consistency

✅ Summary¶

Blueprint-driven documentation is:
Generated and regenerable
Based on DSLs, metadata, and test results
Markdown-first and observability-friendly
Ensures libraries are always:
Well-documented
Traceable
Production-ready

🔁 CI/CD Pipeline Blueprint Mapping¶

This section defines how the backend library blueprint enables automated generation and validation of CI/CD pipelines using metadata-driven instructions. These pipelines are created by agents, aligned with ConnectSoft standards, and compatible with Azure DevOps.

🧩 Blueprint CI/CD Metadata¶

ci:
  enabled: true
  system: azure
  template: library-ci.yml
  test: true
  coverage: true
  publish: true
  publishTarget: connectsoft-artifacts

This instructs the CI/CD Pipeline Agent to scaffold or validate a fully compliant pipeline with build, test, and pack stages.

🧱 Generated Output: `azure-pipelines.yml`¶

trigger:
  branches:
    include:
      - main

variables:
  buildConfiguration: 'Release'

stages:
  - stage: Build
    jobs:
      - job: Build
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '8.x'

          - script: dotnet build --configuration $(buildConfiguration)

  - stage: Test
    condition: and(succeeded(), eq(variables['ci.test'], 'true'))
    jobs:
      - job: Test
        steps:
          - script: dotnet test --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"

  - stage: Pack
    condition: and(succeeded(), eq(variables['ci.publish'], 'true'))
    jobs:
      - job: Pack
        steps:
          - script: dotnet pack -c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)

  - stage: Publish
    dependsOn: Pack
    condition: succeeded()
    jobs:
      - job: PublishToFeed
        steps:
          - task: NuGetCommand@2
            inputs:
              command: 'push'
              packagesToPush: '$(Build.ArtifactStagingDirectory)/*.nupkg'
              publishFeed: 'connectsoft-artifacts'

⚙️ Supported Features¶

Feature	Controlled by
Test Execution	`ci.test`
Coverage Checks	`ci.coverage`
Packaging	`ci.publish`
Feed Targeting	`publishTarget`

These values may be overridden by CLI args or triggered events.

🧪 CI Failure Agents¶

If a generated or committed pipeline deviates from the blueprint, the CI Drift Detector Agent emits:

ciValidation:
  status: invalid
  reason: "Missing coverage step"
  recommendation: "Regenerate pipeline via PipelineAgent"

📦 NuGet Publishing Flow¶

Publishing is triggered only if:

Tests pass
Coverage meets threshold
ci.publish: true
publishTarget is configured

The NuGetPublisherAgent reads from the same blueprint.

🔁 CI/CD Flow Summary¶

graph TD
    LibraryBlueprint --> PipelineAgent
    PipelineAgent --> azure-pipelines.yml
    azure-pipelines.yml --> Build --> Test --> Pack --> Publish

Hold "Alt" / "Option" to enable pan & zoom

🧠 Prompt Context for CI¶

Used by prompt-injected agents like TestAgent or DriftValidator:

{
  "ci": {
    "enabled": true,
    "system": "azure",
    "template": "library-ci.yml",
    "test": true,
    "coverage": true,
    "publish": true,
    "feed": "connectsoft-artifacts"
  }
}

🧠 Responsible Agents¶

Agent	Role
Pipeline Generator Agent	Creates or updates `azure-pipelines.yml`
CI Drift Validator	Detects deviation from blueprint
Publisher Agent	Pushes `.nupkg` if validated
Doc Generator Agent	Reflects CI status in README.md
Test Agent	Ensures pipeline runs generated tests

✅ Summary¶

CI/CD is defined declaratively in the blueprint
Results in Azure-native pipelines with multi-stage flow
Tied to test, coverage, and publishing gates
Regenerated and validated by multiple factory agents
Guarantees production-readiness and repeatable deployments

📦 Artifact and NuGet Publishing¶

This section explains how backend library blueprints support NuGet packaging and publishing. These features ensure that every library becomes a reusable binary artifact and participates in the broader ConnectSoft ecosystem as a versioned, distributed component.

📘 Blueprint Fields for Artifactization¶

artifact:
  publish: true
  format: nuget
  feed: connectsoft-artifacts
  symbolSupport: true
  includeDocs: true
  autoVersion: true

These fields tell agents to:

Package the library as a .nupkg
Push it to a NuGet-compatible feed
Include PDBs (symbols)
Attach documentation files
Auto-increment versions if not explicitly set

📦 NuGet Package Output Example¶

/bin/Release/
├── ConnectSoft.Extensions.Http.1.0.0.nupkg
├── ConnectSoft.Extensions.Http.1.0.0.snupkg (symbols)
├── ConnectSoft.Extensions.Http.xml (docs)

Generated by the Pack Agent and Publisher Agent based on blueprint metadata.

🔁 NuGet Publishing Flow¶

graph TD
    LibraryBlueprint --> PackAgent --> nupkg
    nupkg --> PublishAgent --> NuGetFeed

Hold "Alt" / "Option" to enable pan & zoom

🛠️ NuGet Properties Injected into `.csproj`¶

<PropertyGroup>
  <PackageId>ConnectSoft.Extensions.Http</PackageId>
  <Version>1.0.0</Version>
  <Authors>ConnectSoft</Authors>
  <Company>ConnectSoft</Company>
  <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
  <IncludeSymbols>true</IncludeSymbols>
  <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  <PackageOutputPath>$(OutputPath)</PackageOutputPath>
</PropertyGroup>

These are derived directly from the blueprint.

🚀 Auto-Versioning Rules¶

If autoVersion: true is set and no version is pinned:

Semantic versioning is incremented based on Git tags
PATCH is bumped for fixes
MINOR for added APIs
MAJOR for breaking changes (future agent support)

🧠 Prompt Context Example¶

{
  "artifact": {
    "format": "nuget",
    "publish": true,
    "feed": "connectsoft-artifacts",
    "symbolSupport": true,
    "includeDocs": true
  }
}

Used to generate packaging metadata and README.md installation sections.

📘 Auto-Injected Docs Section¶

README.md → Installation

## 📦 Installation

This library is published to ConnectSoft NuGet Artifacts.

```bash
dotnet add package ConnectSoft.Extensions.Http
```

Version: `1.0.0`

🧠 Agents Involved¶

Agent	Role
Pack Agent	Builds `.nupkg`, `.snupkg`, `.xml`
Publisher Agent	Pushes to internal or external NuGet feed
CI Agent	Adds publishing stage after validation
Drift Detector Agent	Detects if artifact was modified but not republished
Changelog Agent	Increments version if changes found
Doc Agent	Updates `README.md` install instructions

✅ Summary¶

Artifact publishing is first-class in the blueprint
Enables every library to become:
- A shared component
- A versioned artifact
- A reusable building block
Fully automated, validated, and connected to pipeline, CI, docs, and agents

📈 Observability Hooks and Span Metadata¶

This section defines how backend library blueprints express observability requirements, enabling agents to generate and enforce standardized logging, tracing, and telemetry across all ConnectSoft components.

📘 Observability Fields in Blueprint¶

observability:
  enabled: true
  spans:
    autoWrap: true
    spanPrefix: "library"
    tracedMethods:
      - name: Execute
        level: information
  metrics:
    enabled: false

These fields drive code generation, runtime behavior, and prompt awareness for tracing support.

🪄 Auto-Wrapped Span Output¶

public void Execute()
{
    using var span = tracer.StartSpan("library.execute");

    logger.LogInformation("Executing library behavior...");

    // business logic

    span.SetTag("status", "success");
}

Injected only if observability.spans.autoWrap is true.

🧠 Traced Methods With DSL Hooks¶

Blueprints may reference span-definitions DSLs to declare span shapes:

dslRefs:
  - observability/span-definitions.yaml

These DSLs define:

📛 Span names
🏷️ Tags
🔄 Trace propagation
🚨 Error annotation rules

📊 Generated Observability Metadata¶

{
  "observability": {
    "spans": {
      "enabled": true,
      "prefix": "library",
      "tracedMethods": ["Execute"]
    },
    "metrics": {
      "enabled": false
    }
  }
}

Used by span generators, test agents, and tracing dashboards.

📈 Metrics (Optional)¶

When metrics.enabled: true, blueprint agents may inject:

IMetricsRecorder interface
Counter and Timer wrappers
.ObserveDuration() logic

This is disabled by default in lightweight libraries.

🧪 Observability Test Hooks¶

If observability is enabled, test agents may auto-generate:

[TestMethod]
public void ShouldEmitSpan_WhenExecuteRuns()
{
    var sink = new TestSpanSink();
    var service = new MyLibraryService(sink);
    service.Execute();
    Assert.IsTrue(sink.Contains("library.execute"));
}

📘 Observability in Docs¶

README.md → Observability Section

## 📈 Observability

This library emits the following spans:

- `library.execute`: Wraps core behavior
- Logs: `ILogger<T>` is injected automatically

Trace IDs are propagated via standard headers.

🧠 Agents That Use Observability Metadata¶

Agent	Purpose
Span Generator Agent	Injects span wrappers and tracing context
Test Agent	Validates spans are emitted correctly
Prompt Agent	Suggests usage patterns with observability
Doc Generator Agent	Lists emitted spans and trace IDs
Drift Agent	Flags span metadata mismatch or missing wrappers

🧠 Blueprint-to-Code Flow¶

flowchart TD
    Blueprint["library-blueprint.yaml"]
    --> SpanGenerator["tracer.StartSpan(...)"]
    --> TestAgent["Assert span presence"]
    --> DocGenerator["📈 Observability section"]

Hold "Alt" / "Option" to enable pan & zoom

✅ Summary¶

Blueprint observability fields enable:
Auto-wrapping methods in spans
Standard trace ID propagation
Testable telemetry hooks
DSL span definitions provide declarative span shapes
Enables platform-wide tracing from libraries → services → APIs

🛡️ Exception Handling and Fault Safety¶

This section defines how backend library blueprints encode safe exception handling policies that ensure consistent behavior, graceful failure modes, and enhanced debuggability. It guides the generation of try/catch blocks, error logging, and recoverability logic.

📘 Blueprint Metadata for Exception Handling¶

exceptionHandling:
  enabled: true
  logLevel: error
  includeTraceId: true
  wrapUnexpected: true
  fallbackReturnValues:
    Execute: null

This metadata enables agents to scaffold standardized defensive logic for every library method or API.

🧱 Scaffolding Output¶

MyLibraryService.cs with safe execution logic

public string Execute()
{
    try
    {
        using var span = tracer.StartSpan("library.execute");

        // business logic here
        return "success";
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Unhandled exception in Execute with trace ID: {TraceId}", traceContext.TraceId);

        if (wrapUnexpected)
            throw new MyLibraryException("Unexpected error", ex);

        return null;
    }
}

TraceId injection and fallback values are based on blueprint configuration.

🧠 Blueprint → Prompt Context¶

{
  "exceptionHandling": {
    "enabled": true,
    "wrapUnexpected": true,
    "fallbackReturnValues": {
      "Execute": null
    }
  }
}

Agents generating examples, tests, and docs adapt their content to match this safety pattern.

⚠️ DSL for Exception Shapes¶

In larger systems, exception types may be described in reusable DSLs:

exceptions:
  - name: MyLibraryException
    base: Exception
    code: "MLIB_001"
    description: Generic failure in MyLibrary

Blueprints referencing this DSL enable agents to auto-generate:

Exception classes
Mapping tables
Recovery test scenarios

📘 Agent Roles and Handlers¶

Agent	Role
Exception Wrapper Agent	Injects safe try/catch + fallback returns
Test Agent	Asserts no unhandled throws during runtime
Doc Generator Agent	Describes exception safety and fallback policy
Drift Agent	Flags missing handlers vs. blueprint
Observability Agent	Ensures trace IDs are logged with exceptions

🧪 Test Generation with Fault Simulation¶

[TestMethod]
public void ShouldWrapException_WhenUnexpectedErrorOccurs()
{
    var service = new MyLibraryService(MockLogger());
    var result = service.Execute(); // internally throws
    Assert.IsNull(result); // fallback value from blueprint
}

📘 README.md Section¶

## 🛡️ Fault Handling

- All exceptions are wrapped in `MyLibraryException`
- Trace IDs are logged with every fault
- Fallback return for `Execute`: `null`

🧠 Blueprint Enforcement Diagram¶

flowchart TD
    Blueprint --> CodeAgent --> TryCatchBlock
    Blueprint --> TestAgent --> FaultRecoveryTest
    Blueprint --> DocAgent --> FaultHandlingSection

Hold "Alt" / "Option" to enable pan & zoom

✅ Summary¶

Exception handling is declarative, enforced, and regenerable
Ensures all libraries are:
- Safe to call
- Observable under failure
- Predictable in fallback behavior
Wraps errors, logs properly, and returns safe values

🔐 Security Metadata and Safe Defaults¶

This section defines how backend library blueprints express security requirements and enable agents to enforce safe-by-default behavior. It focuses on:

Secure configuration expectations
Credential handling
Header masking
Safe error reporting
Static analyzers and validation rules

📘 Security Metadata in Blueprint¶

security:
  enforceSafeDefaults: true
  secrets:
    - TokenEndpoint
    - ClientSecret
  sanitizeLogs: true
  rejectUnencryptedConnections: true
  requireSslConfig: true

This metadata is used by generation, validation, and observability agents to inject secure design patterns.

🔐 Injected Secure Patterns¶

Credential Masking Example

logger.LogDebug("Sending to {Url} with client secret: [REDACTED]");

Configuration Validation Example

if (!options.BaseUrl.StartsWith("https://"))
    throw new SecurityException("Unencrypted endpoint not allowed");

Log Sanitization DSL

logSanitizerRules:
  - pattern: ".*secret.*"
    replacement: "[REDACTED]"
  - pattern: "token=.*"
    replacement: "token=[FILTERED]"

🧠 Security in Prompt Context¶

{
  "security": {
    "sanitizeLogs": true,
    "requireSslConfig": true,
    "secrets": ["ClientSecret"],
    "enforceSafeDefaults": true
  }
}

Used to guide generation of secure defaults, test coverage, and inline comments.

🧪 Secure Defaults Validation¶

Rule	Example
Enforce HTTPS URLs	Configuration rejected if `http://` is used
Fail fast on missing secrets	Constructor throws if secret not set
Do not log secrets	All sensitive values masked in log output

🧠 Agents Using Security Metadata¶

Agent	Role
Code Generator Agent	Injects guards, redactions, validation
Security Validator Agent	Scans code for policy violations
Log Agent	Adds sanitization filters
Prompt Agent	Annotates generated output with [REDACTED]
Doc Generator Agent	Emits guidance in `runbook.md` and `README.md`

📘 README.md Section (Security)¶

## 🔐 Security

- All credentials are masked in logs
- HTTP is rejected at runtime; HTTPS required
- `ClientSecret` is never logged
- Config validation enforces secure endpoints

✅ Summary¶

Security is not bolted on — it's part of the blueprint contract
Enforces safe defaults and prevents accidental credential leakage
Log sanitization, URL validation, and secret redaction are all agent-driven
Enables every generated library to be production-hardened by default

🗃️ Versioning and Change Tracking¶

This section defines how backend library blueprints encode versioning policies, changelog automation, and semantic compatibility rules that help ensure traceable evolution of each ConnectSoft library across releases.

📘 Versioning Fields in Blueprint¶

versioning:
  strategy: semver
  initial: 1.0.0
  autoBump: patch
  changelog: true
  compatibility:
    breakOn: ["publicApi", "options", "nugetContract"]

These fields are interpreted by agents to:

Set initial and next versions
Detect what changes trigger major/minor/patch bumps
Emit changelog entries
Block builds if breaking changes are detected without version bump

📦 `.csproj` Version Injection¶

<PropertyGroup>
  <Version>1.0.0</Version>
</PropertyGroup>

Auto-updated via commit hooks or changelog analysis if autoBump is enabled.

🔁 Changelog Generation¶

CHANGELOG.md (generated)

## [1.1.0] - 2025-06-07

### Added
- Support for OAuth2 retry policies

### Fixed
- Logging issue with empty token

### Changed
- Internal token caching behavior

---

The Changelog Agent parses git diff, blueprint metadata, and DSL diffs to compile structured updates.

🚨 Compatibility Break Detection¶

Agents analyze:

✅ Public API surface (via Roslyn)
✅ options.yaml schema
✅ NuGet contract types

If changes are detected without a major version bump, build fails:

❌ Detected breaking change in `HttpAuthOptions`. Expected version bump to MAJOR.

🧠 Prompt Context Metadata¶

{
  "versioning": {
    "strategy": "semver",
    "autoBump": "patch",
    "initial": "1.0.0",
    "compatibility": {
      "breakOn": ["publicApi", "options"]
    }
  }
}

Used by doc agents, test agents, and validation routines.

🧪 Test Generation for Backward Compatibility¶

[TestMethod]
public void ShouldSupportPreviousTokenOption()
{
    var config = new ConfigurationBuilder()
        .AddInMemoryCollection(new Dictionary<string, string>
        {
            ["HttpAuth:BaseUrl"] = "https://example.com",
            ["HttpAuth:TokenEndpoint"] = "/token"
        })
        .Build();

    var service = CreateLibraryService(config);
    Assert.IsNotNull(service);
}

Ensures old configurations still pass.

📘 Documentation Section¶

## 🗃️ Versioning

- Version: `1.1.0` (SemVer)
- Changelog: [CHANGELOG.md](./CHANGELOG.md)
- Breaking changes auto-detected via public API diff
- Auto-bumps minor version if features added

🧠 Agents Using Versioning Metadata¶

Agent	Role
Changelog Agent	Generates or updates `CHANGELOG.md`
Versioning Agent	Increments version in `.csproj`
Diff Validator Agent	Detects breaking changes
CI Agent	Blocks release if version not bumped
Doc Agent	Updates version metadata in README

✅ Summary¶

Versioning is semantically enforced through blueprint-driven metadata
Supports automated changelog generation and compatibility testing
Enables release-safe lifecycle management for all backend libraries
Reduces release errors, confusion, and silent breakages across platform

🧬 Blueprint DSL and Template Reference¶

This section defines how backend library blueprints can reference external DSLs and shared scaffolding templates to promote consistency, reduce duplication, and enable traceable code generation.

📘 Blueprint DSL References¶

dslRefs:
  - options/http-auth-options.yaml
  - observability/span-definitions.yaml
  - validation/ruleset.yaml

Each referenced file defines reusable, declarative content that blueprint agents can inject directly into the generated library.

📂 DSL Example: `http-auth-options.yaml`¶

className: HttpAuthOptions
sectionName: HttpAuth
properties:
  - name: BaseUrl
    type: string
    required: true
  - name: ClientSecret
    type: string
    required: true
    isSecret: true

This file is referenced instead of embedding the same YAML structure inside each blueprint.

📂 DSL Example: `span-definitions.yaml`¶

spans:
  - name: library.execute
    tags:
      - name: status
        values: [success, error]

Allows centralized control over span shapes and naming conventions.

🧩 Blueprint Template References¶

templates:
  base: ConnectSoft.BaseLibrary
  includes:
    - ConnectSoft.DI.Support
    - ConnectSoft.Logging.Standard

These reference scaffolding templates, such as .tt, .cs.tpl, .md.hbs, or structured YAML/C# blocks. Templates can include:

Code snippets
DI configuration
Logging wrappers
Documentation stubs
Test example formats

🔁 Blueprint to Template Flow¶

flowchart TD
    Blueprint --> DSLLoader --> DSLs["options.yaml, spans.yaml"]
    Blueprint --> TemplateResolver --> Templates["base + includes"]
    Templates --> Generator --> SourceFiles

Hold "Alt" / "Option" to enable pan & zoom

📦 Benefits of DSL and Template Linking¶

Feature	Advantage
DSL reuse	Standard schema for config, spans, exceptions
Easier updates	Change one DSL, affects all referencing libraries
Template versioning	Keep core logic consistent across all blueprints
Prompt injection	DSL values are injected into prompts without duplication
Source traceability	Links back to DSL/Template used for every generated line

🧠 Agents Using DSL/Template References¶

Agent	Purpose
DSL Loader Agent	Parses and validates DSLs before use
Template Engine Agent	Applies .hbs/.tpl to generate files
Doc Generator Agent	Loads DSL into docs
Drift Validator Agent	Detects mismatch between DSL/template and output
Prompt Agent	Injects DSL as part of few-shot examples/context

📘 Blueprint Metadata in Context¶

{
  "dslRefs": ["options/http-auth-options.yaml"],
  "templates": {
    "base": "ConnectSoft.BaseLibrary",
    "includes": ["ConnectSoft.Logging.Standard"]
  }
}

Agents can dynamically extend code, docs, tests, and examples based on these references.

✅ Summary¶

Blueprints are modular and extensible via DSLs and templates
Keeps business logic, standards, and formatting centralized and versioned
Enables thousands of libraries to conform to shared specs and evolve in sync
Supports traceable regeneration and efficient prompt injection

🧪 Quality Score and Drift Indicators¶

This section defines how backend library blueprints support quantifiable quality scoring and drift detection. These mechanisms enable the AI Software Factory to continuously assess, validate, and enforce the integrity of generated libraries.

📘 Blueprint Fields for Quality and Drift¶

quality:
  scoringEnabled: true
  maxScore: 100
  thresholds:
    pass: 85
    warn: 70
    fail: <70
  indicators:
    - name: testCoverage
      weight: 0.3
    - name: docCompleteness
      weight: 0.2
    - name: ciPipelineMatch
      weight: 0.2
    - name: driftStatus
      weight: 0.3

These are used by validator agents to produce scores and highlight weaknesses.

📊 Output: Quality Score Report¶

{
  "qualityScore": 88,
  "status": "pass",
  "indicators": {
    "testCoverage": 92,
    "docCompleteness": 100,
    "ciPipelineMatch": 80,
    "driftStatus": 70
  }
}

Generated automatically after every regeneration or commit.

📉 Drift Indicators¶

Drift indicators track misalignment between:

🔄 Blueprint vs. generated output
🧪 Tests vs. CI config
📘 Documentation vs. actual API surface
🎯 Expected vs. measured observability span shapes

Example:

drift:
  spanMismatch: true
  testDrift: false
  docOutdated: true

Each drift type lowers the score and triggers regeneration if needed.

🧠 Quality Evaluation Agents¶

Agent	Purpose
Quality Scoring Agent	Computes score per indicators
Drift Detector Agent	Compares blueprint vs. artifact
CI Drift Validator	Validates test execution in pipeline
Doc Drift Agent	Detects stale markdown
Blueprint Corrector Agent	Suggests fixes if thresholds are not met

📘 Dashboard Example¶

## 🧪 Quality Score

- Score: `88/100` ✅
- Status: PASS
- Indicators:
  - ✅ Test Coverage: 92%
  - ⚠️ CI/Pipeline Match: 80%
  - ✅ Documentation Complete
  - ⚠️ Span Mismatch: Detected

🔁 Integration into CI/CD¶

Scores may be used to block builds:

- task: QualityScoreCheck@1
  inputs:
    minScore: 85

If score is below thresholds.pass, pipeline fails and comments are injected via GitOps agent.

📦 Prompt Context for Self-Healing¶

{
  "qualityScore": 72,
  "drift": {
    "docOutdated": true,
    "ciMismatch": false
  },
  "action": "recommend_regeneration"
}

This guides Prompt Agents and Drift Correctors to suggest fixes and regenerate sections selectively.

✅ Summary¶

Quality score makes blueprint compliance measurable
Drift detection ensures blueprints remain the single source of truth
Thresholds help prevent silent regressions
Supports intelligent agent collaboration to maintain software health at scale

🧰 Internal Blueprint Validation Flow¶

This section outlines how blueprint metadata is internally validated, enriched, and sanity-checked before being used by generation or orchestration agents. This validation step ensures that only structurally correct, semantically complete, and safe blueprints are accepted.

✅ Validation Goals¶

❌ Prevent malformed or ambiguous fields
✅ Ensure required sections are present
✅ Normalize default values
✅ Check DSL/template references exist and resolve
🚫 Block invalid combinations (e.g. CI enabled without tests)

📘 Blueprint Lifecycle Hooks¶

flowchart TD
    Draft["raw-blueprint.yaml"] --> ValidatorAgent
    ValidatorAgent --> EnrichedBlueprint["normalized + resolved"]
    EnrichedBlueprint --> GenerationAgent

Hold "Alt" / "Option" to enable pan & zoom

All agent execution begins with validated and enriched blueprints.

🔍 Static Validation Checks¶

Rule	Description
`ci.enabled` requires `test: true`	Prevents invalid pipeline
`versioning.strategy` must be `semver`	Rejects unknown version models
`observability.spans` requires `enabled: true`	Span list only valid if enabled
`artifact.feed` must be resolvable	Validates NuGet target
`dslRefs` must point to existing DSLs	Prevents broken imports

🔧 Enrichment Examples¶

# Before
test: true

# After Enrichment
test:
  framework: MSTest
  baseClass: TestBase

# Before
observability: true

# After Enrichment
observability:
  spans:
    autoWrap: true
    spanPrefix: "library"
  metrics:
    enabled: false

Enrichment applies factory-wide defaults, even when blueprint authors omit detail.

🧠 Validator Agent Output¶

{
  "status": "valid",
  "normalized": true,
  "resolved": true,
  "issues": [],
  "enrichedFields": ["test.framework", "observability.metrics"]
}

❌ Example of Rejected Blueprint¶

ci:
  enabled: true
  test: false  # ❌ Invalid: pipeline requires tests

Output:

{
  "status": "invalid",
  "issues": [
    "CI is enabled but test section is disabled"
  ]
}

🧠 Agents Involved in Validation Flow¶

Agent	Role
Blueprint Validator Agent	Entry-point static/dynamic validation
Enrichment Agent	Applies implicit factory defaults
DSL Link Resolver Agent	Validates and loads DSL contents
Template Reference Agent	Resolves templates and checks version compatibility
Diagnostics Agent	Attaches traceable validation logs and issues

📘 Log Snapshot¶

[✓] DSL 'options/http-auth-options.yaml' loaded
[✓] Template 'ConnectSoft.BaseLibrary' resolved
[✓] Enriched: test.framework = MSTest
[✓] Enriched: observability.metrics.enabled = false

✅ Summary¶

All blueprints are validated and normalized before being executed
Ensures generation is predictable, safe, and reproducible
Enables consistent behavior across 1000s of libraries even with minimal user input
Rejects invalid configurations and guides users to fix issues early

🧩 Blueprint Execution Entry Points and Consumers¶

This section defines the key entry points where blueprints are consumed by agents or tools and how they trigger downstream workflows. It ensures that backend library blueprints can be picked up and executed at any phase: generation, validation, drift repair, or documentation.

🚪 Entry Points for Execution¶

Trigger	Description
`factory init`	Creates blueprint stub and attaches DSLs
`agent generate`	Triggers generation of source, test, doc, CI
`agent validate`	Performs quality scoring, drift detection
`pipeline run`	CI pipeline uses blueprint to verify structure
`doc sync`	Documentation Agent updates markdown from blueprint

These entry points support both design-time and runtime blueprint consumption.

🔄 Execution Flow Diagram¶

flowchart TD
    Blueprint --> Validator --> Generator --> OutputArtifacts
    Blueprint --> DriftDetector --> Regeneration
    Blueprint --> QualityScorer --> ScoreReport
    Blueprint --> DocumentationAgent --> MarkdownFiles
    Blueprint --> CI/CDPipeline --> Test/Build/Pack

Hold "Alt" / "Option" to enable pan & zoom

📘 Agent Types That Consume Blueprints¶

Agent Type	Purpose
Code Generation Agent	Produces `.cs`, `.csproj`, DI setup
Test Agent	Creates `*.Tests.cs`, helpers
Pipeline Agent	Emits `azure-pipelines.yml`
NuGet Publisher Agent	Builds and pushes `.nupkg`
Drift Validator Agent	Detects changes from blueprint
Documentation Agent	Renders all markdown
Versioning Agent	Increments versions as needed
Prompt Injection Agent	Loads blueprint context into semantic prompts

📁 Output Artifacts from Blueprint¶

/src/
├── MyLibrary.cs
├── MyLibraryOptions.cs
/tests/
├── MyLibrary.Tests.cs
/docs/
├── README.md
├── features.md
/ci/
├── azure-pipelines.yml
/dist/
├── MyLibrary.1.0.0.nupkg

Each artifact is traceable to the exact portion of the blueprint that produced it.

🧠 Execution Metadata in Context¶

{
  "source": "library-blueprint.yaml",
  "executedBy": "CodeGenerationAgent",
  "context": {
    "observability.spans": true,
    "ci.enabled": true
  }
}

Used to track trace lineage and ensure reproducibility.

🧠 Runtime Consumers¶

Some long-lived agents or factory services also consume blueprint metadata to adjust live behavior or provide real-time documentation:

Developer portal auto-documentation
OpenAPI doc patching
Live test dashboards
Observability dashboards

📘 Example Use Case¶

Developer triggers: agent generate backend-library-blueprint.yaml Result:

MyLibrary.cs + DI setup

README.md + runbook.md

azure-pipelines.yml

CHANGELOG.md

NuGet packaging and optional publish

✅ Summary¶

Blueprints are consumed at multiple stages of the software factory pipeline
Each artifact has a well-defined agent and traceable input
Enables end-to-end automation, auditability, and regeneration across design, build, test, and release flows

🔄 Agent Interoperability and Event Mesh Integration¶

This section defines how backend library blueprints participate in the agentic event mesh, enabling seamless event-driven collaboration between AI agents, factory subsystems, and external orchestrators.

🧠 Blueprint → Event Emission¶

When a blueprint is created, updated, or executed, it triggers well-known events:

events:
  - type: BlueprintCreated
    topic: blueprints.lifecycle
  - type: BlueprintValidated
    topic: blueprints.lifecycle
  - type: ArtifactGenerated
    topic: blueprints.outputs
  - type: QualityScoreComputed
    topic: quality.scores

These events flow through the ConnectSoft Event Mesh (e.g. Azure Event Grid or Kafka).

📡 Sample Event: `BlueprintValidated`¶

{
  "eventType": "BlueprintValidated",
  "subject": "libraries/ConnectSoft.Extensions.Http",
  "data": {
    "status": "valid",
    "qualityScore": 88,
    "version": "1.1.0"
  },
  "eventTime": "2025-06-07T18:30:00Z",
  "dataVersion": "1.0"
}

🔁 Event Mesh Integration Flow¶

flowchart TD
    Blueprint --> ValidationAgent --> Event["BlueprintValidated"]
    Event --> EventBus
    EventBus --> QualityDashboard
    EventBus --> ArtifactStorage
    EventBus --> RegenerationAgent

Hold "Alt" / "Option" to enable pan & zoom

Agent	Triggered By
Drift Detector Agent	`BlueprintValidated`, `ArtifactGenerated`
Quality Score Agent	`BlueprintValidated`
Doc Generator Agent	`BlueprintUpdated`
CI/CD Sync Agent	`ArtifactGenerated`, `BlueprintUpdated`
Regeneration Agent	`DriftDetected`, `ScoreBelowThreshold`
Orchestration Gateway	All events prefixed with `Blueprint` or `Artifact`

📘 Use Case: CI Pipeline as Event Consumer¶

CI pipeline waits for a BlueprintValidated event before building:

trigger:
  branches:
    include:
      - main

resources:
  containers:
    - container: validation
      image: connectsoft/validation-agent:latest

steps:
  - task: EventGridTrigger@1
    inputs:
      eventType: BlueprintValidated

📘 Use Case: Developer Portal Auto-Refresh¶

Upon ArtifactGenerated, the developer portal receives:

{
  "library": "ConnectSoft.Extensions.Http",
  "docsUpdated": true,
  "version": "1.1.0"
}

It then refreshes docs and NuGet links automatically.

🧩 Event Naming Conventions¶

Event Type	Description
`BlueprintCreated`	When a new blueprint is scaffolded
`BlueprintValidated`	Validation completed (valid/invalid)
`ArtifactGenerated`	Output built (code, docs, nuget)
`DriftDetected`	Drift discovered in validation
`QualityScoreComputed`	Scoring complete with metadata

✅ Summary¶

Blueprints are first-class event citizens in the ConnectSoft AI Factory
Event-driven integration allows loose coupling and automation across agents
All blueprint-related events are structured, typed, and real-time
Promotes scalability, traceability, and agent swarm behaviors

🧪 Blueprint-Based Test Generation and Coverage Hooks¶

This section defines how backend library blueprints drive automated test generation, coverage validation, and test drift detection. It ensures every backend library maintains test quality, safety nets, and observability into test effectiveness.

🧬 Blueprint Fields for Test Configuration¶

test:
  enabled: true
  framework: MSTest
  includeExamples: true
  coverageThreshold: 90
  baseClass: TestBase
  coverageTrackedPaths:
    - src/
    - generated/

This tells agents how to:

Scaffold unit and functional tests
Configure CI to enforce coverage
Generate example-based and DSL-driven tests
Apply base test frameworks and helpers

📂 Output: Auto-Generated Test Files¶

/tests/
├── MyLibrary.Tests.cs
├── MyLibraryOptionsValidationTests.cs
├── MyLibraryObservabilityTests.cs

🧪 Test Agent Responsibilities¶

Responsibility	Output
Generate `*.Tests.cs`	Core functionality validation
Validate `HttpAuthOptions`	Based on DSL properties
Emit test coverage reports	Using configured framework
Detect stale/missing tests	Coverage drift, logic orphaning
Validate against coverage threshold	Fail CI if too low

🧠 Coverage Hooks in CI¶

Example for Azure DevOps:

- script: dotnet test --collect:"XPlat Code Coverage"
- task: ReportGenerator@4
  inputs:
    reports: '**/coverage.cobertura.xml'
    targetdir: '$(Build.ArtifactStagingDirectory)/coverage'

- task: Bash@3
  inputs:
    script: |
      coverage=$(cat coverage-summary.json | jq .line.percent)
      if (( $(echo "$coverage < 90" | bc -l) )); then
        echo "❌ Coverage too low"
        exit 1
      fi

This enforces coverageThreshold: 90 as declared in blueprint.

📘 Prompt Injection from Blueprint¶

{
  "test": {
    "framework": "MSTest",
    "coverageThreshold": 90,
    "baseClass": "TestBase"
  }
}

Used to craft prompt-based test suggestions and template parameters.

📘 Generated Test Example¶

[TestMethod]
public void ShouldValidateBaseUrl()
{
    var options = new HttpAuthOptions { BaseUrl = null };
    var result = validator.Validate(options);
    Assert.IsFalse(result.IsValid);
}

This is auto-generated from the options.yaml DSL + blueprint reference.

📉 Drift Detection Hooks¶

If test coverage declines or code mutates with no new tests:

{
  "testDrift": true,
  "uncoveredLines": ["HttpAuthHandler.cs:53", "RetryPolicy.cs:22"]
}

These trigger regeneration requests or quality alerts.

🧠 Test-Centric Agents¶

Agent	Role
Test Generation Agent	Creates tests per blueprint intent
Test Coverage Agent	Computes % per file/folder
CI Drift Validator	Detects mismatch with test coverage expectations
Observability Test Agent	Validates spans and log outputs
Blueprint Drift Resolver	Suggests coverage remediation code

✅ Summary¶

Blueprints define how tests are generated, structured, and enforced
Guarantees that all code has backed coverage and traceable test drift detection
Supports intelligent CI integration with coverage fail gates
Promotes reliable, production-grade libraries from day one

🧾 Final Recap and Blueprint Capabilities Summary¶

This section consolidates all blueprint-driven features into a structured summary, capturing how backend library blueprints serve as the authoritative specification for generating production-grade, secure, observable, and reusable .NET libraries in the ConnectSoft AI Software Factory.

🧱 Blueprint Structure Summary¶

Section	Purpose
`metadata`	Name, description, domain, tags
`templates`	References to shared scaffolding
`dslRefs`	Declarative schema and behavior injection
`artifact`	NuGet packaging, publishing, versioning
`observability`	Span, metric, and trace hooks
`exceptionHandling`	Fault safety, trace ID logging
`security`	Credential redaction, HTTPS enforcement
`versioning`	SemVer, auto-bump, changelog generation
`ci`	Azure DevOps pipeline generation
`test`	Unit test coverage, thresholds, drift detection
`quality`	Scoring, thresholds, coverage impact
`events`	Triggers for orchestration and traceability

📘 Key Capabilities Enabled¶

✅ Declarative Ownership Each blueprint defines what a library does, how it's built, tested, deployed, and versioned — without writing any code manually.

✅ End-to-End Automation Agents use blueprints to drive generation of:

Code
Options
Tests
CI pipelines
Documentation
Observability setup
NuGet artifacts
Changelogs

✅ Self-Healing and Regeneration Any drift from blueprint causes agents to trigger regeneration or emit correction prompts.

✅ Extensibility via DSLs & Templates Blueprints don't duplicate logic — they link to reusable DSLs, scaffolding templates, and prompt patterns.

✅ Traceable and Observable Every artifact emitted by the factory is traceable to the blueprint version, agent that generated it, and source metadata.

✅ Event-Driven Participation Blueprint lifecycle events allow coordination across microservices, portals, pipelines, and documentation systems.

🧠 Factory Insight Diagram¶

flowchart TD
    Blueprint["📘 backend-library-blueprint.yaml"]
    --> Validator
    --> Generator
    --> TestAgent
    --> DocAgent
    --> CI/CDPipeline
    --> NuGetPublisher
    --> QualityScoreAgent
    --> EventMesh

Hold "Alt" / "Option" to enable pan & zoom

📦 Output Manifest Example¶

{
  "library": "ConnectSoft.Extensions.Http",
  "version": "1.2.0",
  "artifacts": [
    "MyLibrary.cs",
    "MyLibrary.Tests.cs",
    "README.md",
    "CHANGELOG.md",
    "azure-pipelines.yml",
    "MyLibrary.1.2.0.nupkg"
  ],
  "qualityScore": 91,
  "status": "drift-free",
  "generatedBy": "CodeGenAgent@2025-06-07"
}

🔄 Regeneration Entry Points¶

Trigger	Result
Blueprint change	Regenerates all affected outputs
Drift detected	Partial regeneration (tests/docs only)
Score < threshold	Prompts regeneration with improvements

📘 Final Note¶

The backend library blueprint is not a static spec — it is a living contract between agents, developers, and the ConnectSoft AI Software Factory.

It enables fully autonomous production and evolution of backend libraries at scale, securely, and with complete traceability.

🗂️ Backend Library Blueprints¶

🧭 Introduction to Backend Library Blueprints¶

📘 What Is a Backend Library Blueprint?¶

🧱 What It Enables¶

🧠 Factory Use Cases¶

🔧 Blueprint Output Examples¶

🎯 Blueprint Role in the Platform¶

🧠 Agents That Use This Blueprint¶

✅ Summary¶

🧱 Blueprint Structure Overview¶

📂 Core Structure of the Blueprint¶

📘 Key Blueprint Files Explained¶

🧱 Blueprint vs Output Structure¶

🧩 Output Directories (After Execution)¶

📦 References to Other Artifacts¶

📘 Example: Minimal library-blueprint.yaml¶

✅ Summary¶

🧭 Blueprint DSL & CLI Parameters¶

🧩 CLI Parameters → DSL Integration¶

🔧 CLI Parameters Examples (mapped to DSL fields)¶

🧬 Blueprint Snippet With CLI Parameters Reflected¶

🧠 DSL Purpose and Reusability¶

💡 Prompt Template Impact¶

🛠️ CLI Usage Example¶

✅ Summary¶

🧪 Test and CI/CD Metadata¶

🧪 Test Metadata in the Blueprint¶

🧪 Output of the Test Blueprint¶

🧪 Example Test Scaffolding Output¶

🔁 Regeneration Support¶

⚙️ CI/CD Metadata¶

🔁 Test and Coverage Flow¶

🧠 Agent Usage¶

✅ Summary¶

🗂️ Project Layout Convention¶

📁 Standard Folder Structure¶

📦 Project Structure Expectations¶

🧩 Blueprint Enforcement¶

💡 Naming Convention Rules¶

🧪 Naming Examples¶

🧠 AI Prompt Context Injection¶

🧠 Agents Using Layout¶

✅ Summary¶

🧩 Code Scaffolding and Options Binding¶

🧾 options.yaml: Declarative Configuration Definition¶

🧱 Generated Output – Options Class¶

🧪 Validation Hook in DI¶

📘 Blueprint Fields That Trigger Options Scaffolding¶

📚 Agentic Documentation From Options¶

🧠 Agent Roles for Options¶

✅ Summary¶

♻️ DI and Logging Integration Blueprint¶

🧰 DI Integration Blueprint Fields¶

📦 DI Scaffolding Output¶

🔍 Logging Scaffolding Output¶

🧠 AI Prompt Enrichment¶

🧪 Test Validation of DI¶

🧩 Blueprint to Runtime Flow¶

🧠 Agent Roles¶

✅ Summary¶

🎯 Multi-TFM and Targeting Metadata¶

📘 Targeting Field in Blueprint¶

🧱 Output: Multi-TFM .csproj¶

🧪 TFM Testing Matrix¶

🧬 Compatibility Enforcement¶

📦 NuGet Packaging Impact¶

🧠 Prompt Context Enrichment¶

🧠 Agents Using TFM Metadata¶

✅ Summary¶

🧪 Test Project Blueprint Structure¶

🧱 Standard Test Project Output¶

📘 Blueprint Test Metadata¶

🧪 Scaffolding Example: MyLibraryTests.cs¶

🧰 Shared Helpers in /TestHelpers/¶

🧠 CI Integration Hooks¶

📦 Packaging Impact¶

🧠 AI Prompt Context Example¶

🧠 Agents Using Test Blueprint Structure¶

✅ Summary¶

🔧 Cross-Cutting Concerns Metadata¶

📘 Example: Minimal `library-blueprint.yaml`¶

🧾 `options.yaml`: Declarative Configuration Definition¶

🧱 Output: Multi-TFM `.csproj`¶

🧪 Scaffolding Example: `MyLibraryTests.cs`¶

🧰 Shared Helpers in `/TestHelpers/`¶

📄 Example: `README.md` Auto-Generated¶

🧭 Runbook: `runbook.md`¶

🧱 Generated Output: `azure-pipelines.yml`¶

🛠️ NuGet Properties Injected into `.csproj`¶