Skip to content
CAI
Software that uses CAICheck a score

ScottArbeit/Grace

66.9

Adequate · 24 September 2026

217.8k

lines of production code

F#

with Python, Rust

5

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

Grace is a distributed content-addressable storage platform that manages file artifacts through a server, CLI, and multi-language SDKs. It provides capabilities for secure file upload and download, role-based access control, and approval workflows, backed by Orleans actors and Azure infrastructure. The system ensures data integrity using BLAKE3 hashing and supports local caching and Windows library synchronization.

How it got here

2022 — Initial scaffolding and core feature implementation

15 changes.

The project established its foundational structure by migrating to .NET Aspire and implementing core Orleans-based actors for access control and approval workflows. Significant development focused on building out the CLI, SDK, and server components, introducing comprehensive modules for authentication, authorization, and content addressing. This period also involved extensive refactoring of shared libraries and DTOs to support the new distributed architecture and API contracts.

2023–2026 — Aspire migration and SDK generation

37 changes.

The project standardized its development and testing infrastructure by migrating to an Aspire-hosted environment, introducing centralized observability and local resource orchestration. Simultaneously, it established core domain contracts, implemented a robust local cache with integrity verification, and automated the generation of multi-language SDKs from OpenAPI specifications.

Features

Added ADR-0001 ContentBlock CAS Implementation DAG visualization

A new HTML artifact has been added to the artifacts directory that visualizes the Directed Acyclic Graph (DAG) for the ADR-0001 ContentBlock CAS implementation. This interactive page displays the architectural dependencies and relationships between components such as docs, contracts, servers, actors, clients, and garbage collection nodes, providing a clear visual reference for the system's structure.

artifacts · high confidence

Added centralized service defaults for observability and resilience

The new \Extensions.cs\ file in \Grace.Aspire.ServiceDefaults\ introduces a standard configuration pipeline for ASP.NET Core applications. This includes automatic OpenTelemetry instrumentation for logging, metrics, and tracing (with OTLP export support), default health check endpoints at \/health\ and \/alive\, service discovery integration, and standard HTTP client resilience handlers.

src/Grace.Aspire.ServiceDefaults · high confidence

Immutable usage observation storage for artifacts, directories, and text content

The \Grace.Operations.Data\ module now persists immutable size observations for artifacts, directory versions, and text content in dedicated SQL tables (\ops.ArtifactSizeObservation\, \ops.DirectoryVersionSizeObservation\, and \ops.TextContentSizeObservation\). These new tables store declared byte counts and distinct item counts alongside enumeration timestamps, allowing the system to capture and store completed readings separately from additive usage facts. The implementation includes schema bootstrap logic and transactional persistence with scope validation to ensure data integrity.

src/Grace.Operations.Data · high confidence

Initial repository scaffolding and developer onboarding setup

The repository has been initialized with core documentation and configuration files to support development. This includes a \.env.example\ template defining environment variables for Azure services (Cosmos DB, Storage, Service Bus), Redis, Orleans, and authentication (OIDC, PATs), alongside a \global.json\ pinning the required .NET SDK version to 10.0.400. Developer workflows are established via \AGENTS.md\ and \CONTRIBUTING.md\, which outline the use of PowerShell scripts for bootstrapping, Fantomas for F\# formatting, and a structured review process. The project also introduces a new \Grace.Cache\ module, a \SECURITY.md\ policy, and a \code\_of\_conduct.md\, while removing legacy positioning text and updating \.gitignore\ to exclude new build artifacts and local emulator data.

(repo-wide) · high confidence

Introduce Grace SDK TypeScript client and protocol exports

The Grace SDK for TypeScript now exposes a public API surface via \sdk/typescript/grace/src/index.ts\, re-exporting the core \GraceClient\ facade (including file upload/download operations and authentication) and the underlying protocol implementation (including content block encoding, manifest validation, and Blake3 hashing utilities). This change establishes the primary entry point for developers to interact with the Grace storage protocol, providing both high-level client abstractions and low-level cryptographic/protocol primitives.

sdk/typescript/grace/src · high confidence

Introduce Grace operations worker for usage fact ingestion

A new background worker service has been added to ingest operational usage facts from an Azure Service Bus topic and persist them to SQL. The worker reads configuration for the Service Bus topic/subscription and SQL connection string, handles message processing with support for completion, abandonment, and dead-lettering, and manages database schema bootstrapping (creating the database if missing in local debug mode).

src/Grace.Operations.Worker · high confidence

Introduce Grace protocol implementation for content addressing and manifest validation

This change adds the TypeScript implementation of the Grace protocol vectors within the \sdk/typescript/grace/src/protocol\ directory. It introduces core content-addressing logic using Blake3 hashes, including functions to compute addresses for content blocks and file manifests based on specific preimage formats. The update also implements binary serialization and deserialization for content blocks (including trailer and footer handling) and provides a validation engine for file manifests that verifies block ordering, size consistency, and content integrity. Additionally, it includes an eligibility policy to determine whether content should be referenced as a whole file or via a manifest based on size and binary characteristics.

sdk/typescript/grace/src/protocol · high confidence

Introduce TypeScript Grace SDK facade for file transfers

Added a new TypeScript facade in \sdk/typescript/grace/src/facade\ that provides a high-level client for Grace API interactions, specifically enabling file upload and download capabilities. The \GraceClient\ class exposes methods like \uploadFile\ and \downloadFile\ which handle storage scoping, progress reporting via \GraceTransferProgressHandler\, and lifecycle diagnostics. This release also includes supporting infrastructure such as \GraceError\ for structured error handling, \headers.ts\ for client metadata and normalization, and \lifecycle.ts\ for parsing server-side support status headers.

sdk/typescript/grace/src/facade · high confidence

Introduce calibrated local cache artifact storage with integrity verification

The Grace cache now includes a local storage layer for immutable DirectoryVersion ZIP artifacts. This change adds a new \CacheArtifactStore\ that manages the lifecycle of these artifacts, including staging, BLAKE3 hash verification, and final publication to a deterministic file path. It also introduces a \CacheStore\ module that handles the underlying SQLite database, implementing process-level ownership locks to prevent concurrent access and ensuring schema integrity. Users benefit from a more robust local cache that verifies artifact integrity before use and prevents corruption from simultaneous writes.

src/Grace.Cache.Storage · high confidence

Introduce distinct lab and production Azure Bicep infrastructure profiles

The infrastructure now provides two separate Bicep deployment profiles: a disposable \main.lab.bicep\ for short-lived practice using serverless Cosmos DB, serverless Azure SQL, and a TLS-only Redis container, and a \main.production.bicep\ for persistent deployments using provisioned Cosmos DB, Azure Managed Redis with high availability, and a Container App-hosted Grace Server. The production profile enforces secure access by disabling Redis access keys in favor of Microsoft Entra authentication via a user-assigned managed identity, requires immutable container image references, and supports bootstrapping the first SystemAdmin user through OIDC configuration.

infra · high confidence

Introduce internal raw HTTP client for SDK requests

The SDK now includes an internal raw client (GraceRawClient) that handles low-level HTTP interactions. This client abstracts the fetch implementation, allowing for custom fetch injection (supporting Node 20+ or custom options), and standardizes response parsing by automatically handling JSON bodies, plain text, and 204 No Content responses. This change provides a consistent foundation for API calls within the SDK.

sdk/typescript/grace/src/internal · high confidence

Introduce localhost-only Cache service with signed artifact validation and fill coordination

The new Grace.Cache host (src/Grace.Cache) provides a local HTTP boundary for managing cached artifacts. It validates signed artifact grants locally using a refreshable server public key, ensuring only authorized requests access or fill cache entries. The service coordinates concurrent artifact fills, redeeming permits against the server, downloading sources, verifying integrity, and storing results, while exposing a public key endpoint for clients to verify signatures.

src/Grace.Cache · high confidence

Introduce strict WDU lifecycle contract validation and raw projection generation

New PowerShell modules (WduLifecycleContract.psm1, WduLifecyclePacket.psm1, WduLifecycleRawProjection.psm1) enforce strict, ordinal-aware validation of WDU lifecycle data structures and generate exact raw lifecycle projections. This ensures that lifecycle packets and projections adhere to a defined schema, preventing malformed or inconsistent data from being processed.

scripts/modules · high confidence

Introduces Windows Library synchronization with durable state and resumable baseline acquisition

This change adds the core implementation for the Windows Library synchronization feature, introducing new modules in src/Grace.CLI/Library to manage the full lifecycle of Library operations. It establishes a local SQLite database schema (LibraryLocalState) to persist repository participation, catalog metadata, and pending operations with full durability (WAL mode, synchronous=FULL). The system now supports acquiring an immutable baseline from the server (LibraryBaseline), capturing verified file content using SHA-256 and Blake3 hashes into an object store (LibraryFilesystem), and managing operation states such as saved files, directory creations, and renames (LibraryOperation). It also includes logic for uploading prepared content via the existing manifest pipeline (LibraryManifestUpload) and exposes a synchronization status result (LibrarySynchronization) that reports enabled/paused states and pending operation counts. The implementation is Windows-specific, requiring Windows 11 for file stability checks and reparse point validation.

src/Grace.CLI/Library · high confidence

Introduces core domain type contracts for the Grace platform

This change establishes the \src/Grace.Types\ module as the canonical source for shared domain contracts, introducing F\# record and discriminated union types for annotations, artifacts, authorization, automation, branches, content blocks, and directory versions. These types define the data structures and serialization schemas used across the actors, server, CLI, and SDK, ensuring consistent schema handling for features like branch annotations, artifact grants, and content block metadata.

src/Grace.Types · high confidence

Introduces shared core libraries for annotations, content addressing, and authorization

The \src/Grace.Shared\ package now provides a centralized set of reusable utilities consumed by Grace services, SDKs, and tooling. This includes \AnnotationLineCore\ for handling UTF-8 text normalization and effective branch history traversal for annotations, \ContentAddress\ and \ContentBlockFormat\ for BLAKE3-based content addressing and binary block encoding, and \ArtifactGrant\ for issuing and validating ES256-signed cache artifact grants. Additionally, it introduces \Authorization\ helpers for role-based operation catalogs, \DedupeIndex\ for content deduplication logic, and \ApiContractVersion\ for managing API contract versioning.

src/Grace.Shared · high confidence

Introduces structured command output contracts and local command history

The CLI now exposes a formal introspection system for command outputs, allowing automation to rely on stable JSON shapes via the new \CommandOutputContract\ module which defines schemas, examples, and registry metadata for CLI commands. Additionally, a new \grace history\ feature has been added, implemented through \HistoryStorage.CLI.fs\, to record and manage local command-line usage history in a JSONL file, including argument redaction and timing data. These changes are supported by new \SelectProjection\ logic for filtering output fields and updated \Program.CLI.fs\ to integrate these new capabilities into the root parser.

src/Grace.CLI · high confidence

New CLI commands for access control, administration, agents, approvals, and authentication

The CLI now includes several new command modules: \Access\ for managing role assignments and permissions across owners, organizations, repositories, and branches; \Admin\ for managing reminders and system-level tasks; \Agent\ for interacting with automation agents and work items; \Approval\ for handling approval policies and requests; and \Auth\ for managing authentication modes (PKCE, Device Code) and inspecting auth status. These commands provide new capabilities for managing access, administrative tasks, automation, and authentication directly from the command line.

src/Grace.CLI/Command · high confidence

New OpenAPI contract definitions for Approvals, Branches, Cache, Diffs, and Directories

This change introduces the OpenAPI specification files (YAML) for the Approvals, Branches, Cache, Diffs, and Directories modules. It defines the request and response schemas, parameters, and endpoint paths for these areas, establishing the public API surface for managing approval policies and requests, creating and managing branches, preparing and redeeming cache artifacts, computing and retrieving diffs, and creating and retrieving directory versions.

src/OpenAPI · high confidence

New PowerShell diagnostic and observation capture scripts for infrastructure and content metrics

This change introduces a suite of new PowerShell scripts in the \scripts\ directory to support infrastructure validation and content metric diagnostics. \Invoke-GraceInfrastructureLab.ps1\ and \GraceInfrastructureLab.Inventory.ps1\ provide a lifecycle for deploying and validating an Azure infrastructure lab, including secure Redis setup with generated certificates and ACLs. \bootstrap.ps1\ enforces prerequisites like .NET 10 SDK and Docker. Additionally, new scripts (\capture-artifact-size.ps1\, \capture-directory-version-size.ps1\, \capture-text-content-size.ps1\) allow capturing immutable observations of declared bytes and counts, while \diagnose-artifact-size.ps1\, \diagnose-directory-version-size.ps1\, and \diagnose-library-content-size.ps1\ provide admin diagnostics for these metrics. \collect-runtime-metadata.ps1\ gathers environment and process metadata, and \check-wdu-lifecycle-packet.ps1\ validates Working Directory Update packets against documentation.

scripts · high confidence

New SDK client libraries and manifest-backed upload/download capabilities

The Grace SDK now exposes a comprehensive set of typed client wrappers for previously internal or CLI-only server endpoints, including Access (role and path permissions), Admin (repository reminders), Approval (policies and requests), Artifact, Cache, DirectoryVersion, Libraries, and Auth (OIDC configuration). Additionally, the SDK introduces a local upload planner that performs deterministic Rabin chunking and BLAKE3 hashing to generate manifest-backed upload plans, enabling efficient deduplication by uploading only new content blocks, and a corresponding manifest download module that streams and validates reconstructed files from those blocks.

src/Grace.SDK · high confidence

New SDK generator harness and validation scripts

Added PowerShell scripts to automate the generation, verification, and smoke-testing of SDK client code across TypeScript, Python, .NET, and Rust. The new \generate-sdk-clients.ps1\ script produces language-specific metadata files (including contract versions and generator provenance) and a generator report, while \invoke-generator-matrix.ps1\ orchestrates the OpenAPI generator matrix, captures diagnostic evidence, and applies specific fixes (such as semantic union corrections for TypeScript). The \test-sdk-packages.ps1\ script runs smoke tests to ensure the generated SDK packages can be successfully imported and built in each language.

sdk/scripts · high confidence

New local state database worker for persisting Grace status

A new executable, Grace.CLI.LocalStateDb.Worker, has been added to handle the persistence of local state using SQLite. This worker accepts command-line arguments for a database path, root identifiers, and hash values (SHA256 and Blake3), then iteratively updates the local database with Grace status information. It also includes a utility mode to hold a file lease, likely for synchronization coordination between processes.

src/Grace.CLI.LocalStateDb.Worker · high confidence

New parameter models for access, approval, library, promotion, and storage endpoints

The \src/Grace.Shared/Parameters\ directory now includes a comprehensive set of new parameter definition files (Access, Approval, Artifact, Auth, Cache, Library, Policy, PromotionSet, Queue, Reminder, Review, Storage, Validation, Webhook, and WorkItem). These files define the request and response structures for a wide range of new and existing API surfaces, including role-based access control, approval workflows, library synchronization, promotion sets, content block storage discovery, and work item management. This change establishes the data contracts used by the server to handle these specific operations.

src/Grace.Shared/Parameters · high confidence

New request validation, SDK lifecycle, and security middleware

The server request pipeline now includes several new middleware components to improve security, compatibility, and data integrity. The new ValidateIdsMiddleware validates and resolves entity identifiers (Owner, Organization, Repository, Branch) in request bodies, rejecting invalid combinations with 400 errors. The SdkLifecycleMiddleware enforces client version policies, rejecting unsupported CLI/SDK versions with a 426 status and providing update guidance. Security is enhanced by LogRequestHeadersMiddleware, which logs incoming headers while redacting sensitive values like tokens and credentials, and LogAuthorizationFailureMiddleware, which logs details of 401/403 responses for better diagnostics. Additionally, the ApiVersionAliasMiddleware maps legacy API version headers to supported versions, and the TimingMiddleware records request processing times for performance monitoring.

src/Grace.Server/Middleware · high confidence

New server-side authorization, annotation materialization, and approval policy modules

Grace.Server introduces dedicated modules for access control, annotation handling, and approval workflows. The new Access.Server.fs module implements the core HTTP authorization pipeline, including scope parsing (system, owner, organization, repository, branch) and RBAC operation enforcement via the permission evaluator. AnnotationMaterialization.Server.fs adds the capability to materialize file content as text for annotations, handling GZIP decompression, UTF-8 decoding, and strict BLAKE3/SHA-256 hash verification against file versions. Additionally, ApprovalPolicy.Server.fs and ApprovalRequest.Server.fs provide the server-side store and request handling for approval policies, including deterministic ID generation, scope matching, and responder role selection (legacy, repository, or branch). These changes expand the server's internal logic surface for managing access, content annotations, and approval lifecycles.

src/Grace.Server · high confidence

Orleans actor implementation for access control and approval workflows

The Grace.Actors project now includes Orleans grain implementations for access control and approval request management. The AccessControlActor handles system-level role assignments, bootstrapping administrators from environment variables, and persisting role grants and revocations. The ApprovalRequestActor manages the lifecycle of approval requests, including creation, decision recording, expiration, cancellation, and superseding, with idempotent replay support. These actors provide the durable state management for authorization and promotion approval workflows.

src/Grace.Actors · high confidence

SDK generator matrix evidence and prototype clients added

The \sdk/generated/matrix\ directory now contains the issue \#221 generator proof artifacts, including a machine-readable evidence report (\generator-matrix-evidence.json\) and a summary report (\generator-matrix-report.md\). These files document the evaluation of Kiota, NSwag, and OpenAPI Generator against the Grace OpenAPI spec. Kiota and NSwag were rejected due to schema-shape debt, while OpenAPI Generator was accepted with guardrails for TypeScript, Python, and Rust, provided spec validation is skipped. Prototype raw clients generated by OpenAPI Generator are committed under \sdk/generated/matrix/openapi-generator/\ for TypeScript, Python, and Rust, along with their respective CI workflows and configuration files. These generated clients are intended as prototype evidence only and must remain behind handwritten SDK facades.

sdk/generated/matrix · high confidence

SDKs expose API contract and OpenAPI metadata

The .NET, Python, and Rust SDKs now include a minimal client facade that exposes metadata about the underlying API contract. Users can query the API contract version (2023-10-01), the OpenAPI specification version (3.1.2), the SHA-256 hash of the OpenAPI projection, and the SDK generator details (grace-sdk-harness 0.1.0). This allows applications to verify compatibility and traceability against the specific OpenAPI definition used to generate the SDK code.

sdk/dotnet, sdk/python/grace-sdk, sdk/rust/grace-sdk · high confidence

Behavioural changes

Document Python SDK proof status and add generator harness

The Python SDK lane is now explicitly documented as a proof-of-concept lane rather than a supported public SDK facade. This change adds a README detailing the current status (proof harness implemented, raw generated client accepted with guardrails, supported facade deferred) and includes a smoke test script to verify the \GraceClient\ facade import. Additionally, a JSON proof record is added to track the OpenAPI Generator configuration and validation results for the Python language.

sdk/python · high confidence

Expanded error messages and localization infrastructure

The \src/Grace.Shared/Resources\ module now provides a significantly expanded set of localized error messages and status strings for the Grace CLI and server. This change introduces new resource keys for features such as BLAKE3 hash validation, promotion-based workflows (replacing previous merge terminology), and detailed directory version handling. It also adds a utility helper to retrieve localized strings and implements a time-ago text formatter for user-facing timestamps, laying the groundwork for future multi-language support.

src/Grace.Shared/Resources · high confidence

Generated Rust SDK for Grace Server API

The Rust client library in \sdk/generated/matrix/openapi-generator/rust\ has been regenerated to match the Grace Server API specification (version 2023-10-01). This update provides updated API wrappers for managing branches, directories, diffs, caches, and storage operations, ensuring the SDK's request structures and error handling align with the current server endpoints.

sdk/generated/matrix/openapi-generator/rust, sdk/generated/matrix/openapi-generator/typescript-fetch · high confidence

Introduce Aspire AppHost for local and Azure-debug resource orchestration

The project now uses an Aspire AppHost to define and launch the local development environment, replacing previous manual or legacy configurations. It orchestrates core services including Redis, the Grace.Cache (F\#) and Grace.Server projects, and integrates Azure Service Bus, Cosmos DB, and Azure Storage via emulators in local mode or real resources in Azure-debug mode. The AppHost forwards authentication settings (Auth0/OIDC) and authorization bootstrap configurations to the server, manages Orleans cluster identities, and supports test runs with isolated resource lifetimes and optional Service Bus skipping. This provides a unified, reproducible local runtime that mirrors Azure infrastructure for debugging and integration testing.

src/Grace.Aspire.AppHost · high confidence

Introduces structured authorization middleware and explicit endpoint security manifest

The server now enforces access control through a new \AuthorizationMiddleware\ that validates user permissions against a declarative \EndpointAuthorizationManifest\. This manifest explicitly maps every HTTP route to its required operation and resource scope (e.g., \SystemAdmin\ for \/authorize/grant-role\, \RepositoryAdmin\ for \/approval/policy/create\), replacing implicit or ad-hoc checks. The middleware handles authentication state, logs detailed authorization decisions, and returns standardized 401/403 responses, ensuring consistent security enforcement across all API surfaces including webhooks, approvals, and agent sessions.

src/Grace.Server/Security · high confidence

Major refactoring of shared DTOs and namespace structure

The shared data transfer objects in src/Grace.Shared/Dto have been significantly restructured. The file Dto.Shared.fs was rewritten to remove the previous nested module definitions for Branch, Diff, Organization, Owner, Reference, and Repository DTOs, replacing them with a simplified structure that opens Grace.Types.Common and Orleans namespaces. This change aligns the DTO layer with the broader removal of Dapr and implementation of Orleans, updating the underlying type references and serialization attributes to support the new distributed actor model.

src/Grace.Shared/Dto · high confidence

Migration to .NET Aspire and removal of legacy Docker/Tye infrastructure

The project has replaced the legacy Docker Compose and Tye orchestration setup with .NET Aspire. This change removes the \docker-compose.yml\, \docker-compose.override.yml\, \docker-compose.dcproj\, and \tye.yaml\ files, along with the custom \CosmosSerializer\ and \Grace.sln\ solution file. It introduces a new \Grace.slnx\ solution, an \Grace.Aspire.AppHost\ project, and an \aspire.config.json\ to manage the new application model. For users, this simplifies local development and debugging by leveraging Aspire's integrated resource management, replacing the previous manual Docker and Tye configurations.

src · high confidence

New user configuration management and refined default theme colors

The client now introduces a dedicated user configuration system (UserConfiguration.Shared.fs) that persists per-user settings—such as command history preferences and authentication state—into a JSON file within the user's .grace directory, including logic to redact sensitive tokens and flags for destructive commands. Existing repository configuration handling (Configuration.Shared.fs) has been updated to use specific constants for local state file paths and to improve robustness when locating config files across directory trees. Additionally, the default CLI theme (Theme.Shared.fs) has been updated to use specific hex color codes for the 'Verbose' and 'Important' display colors, replacing previous generic color definitions.

src/Grace.Shared/Client · high confidence

Regenerated manifest accounting evidence with corrected validation

The manifest accounting evidence packet in \artifacts/manifest-accounting-measurements\ has been regenerated to include an \artifact-hashes.json\ file that records SHA-256 checksums for all measurement artifacts, and to normalize line endings across the evidence files. This update also fixes the evidence validation logic to correctly enforce freshness invariants, ensuring that the recorded measurement assertions and samples are accurately verified against the underlying data.

artifacts/manifest-accounting-measurements · medium confidence

Validation logic refactored to use ValueTask and modularized error handling

The validation module has been restructured to improve performance and organization. Validation functions now return ValueTask instead of synchronous Results or standard Tasks, and utility helpers like getFirstError have been updated to handle ValueTask arrays. Error definitions have been consolidated into a shared Errors module with a new IErrorDiscriminatedUnion interface, and new error cases (such as BranchIdDoesNotExist and ParentBranchDoesNotAllowPromotions) have been added. Additionally, a new Library.Validation module was introduced to enforce path normalization, uniqueness, and overlap rules for library roots, while Connect and Repository validations now reference the updated RepositoryType enum.

src/Grace.Shared/Validation · high confidence

Test coverage

Added PowerShell test suites for WDU lifecycle contract, packet rendering, and raw projection exports; Added tests for Grace.Cache admission, fill coordination, and host endpoints; Added tests for cache artifact storage and SQLite store locking; Added tests for the TypeScript Grace SDK facade and protocol vectors; Added unit tests for Grace.Types domain contracts; Added unit tests for the Grace operations skeleton, usage storage, and worker ingestion; Added wire-format validation proofs for generated client models; Establishes CLI test project structure and adds initial test coverage; Expanded unit test coverage for server-side logic; Integration test suite migrated to Aspire-hosted emulator stack; New authorization test suite for Grace.Authorization.Tests; Smoke test validates TypeScript SDK facade exports and internal isolation.

Dependencies

Upgrade to .NET 10 and Aspire 13.5

The project has been upgraded to target .NET 10.0 across all components, including the server, CLI, SDKs, and test suites. The Aspire application hosting framework has been updated to version 13.5.0, bringing in corresponding updates to Aspire hosting packages for Azure services (Cosmos DB, Service Bus, Storage) and Redis. This change also updates the .NET SDK harness and associated service defaults to align with the new runtime and Aspire versions.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.

Score

  • CAI 67 → 67 (-0.5)
  • Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 82 → 81 (-0.9)
  • Architecture 94 → 95 (+0.3)
  • Maturity 89 → 90 (+0.9)
  • Readiness 60 → 63 (+2.7)
  • Security 71 → 83 (+11.7)
  • Accessibility 69 → 59 (-9.9)

Resolved (819)

  • Access.parseResource (cognitive 29) (src/Grace.Server/Access.Server.fs)
  • Access.parseResource (cyclomatic 26) (src/Grace.Server/Access.Server.fs)
  • Access.parseScope (cognitive 17) (src/Grace.Server/Access.Server.fs)
  • Access.parseScope (cyclomatic 21) (src/Grace.Server/Access.Server.fs)
  • Access.tryBuildUpsertPathPermission (cognitive 16) (src/Grace.Server/Access.Server.fs)
  • Access.tryParseCurrentContextResource (cognitive 32) (src/Grace.Server/Access.Server.fs)
  • Access.tryParseCurrentContextResource (cyclomatic 19) (src/Grace.Server/Access.Server.fs)
  • AccessControlActor.OnActivateAsync (cognitive 20) (src/Grace.Actors/AccessControl.Actor.fs)
  • AgentCommand.addSummaryHandler (cognitive 76) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.addSummaryHandler (cyclomatic 27) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.bootstrapHandler (cognitive 25) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.bootstrapHandler (cyclomatic 16) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStartWith (cognitive 144) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStartWith (cyclomatic 28) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStatusWith (cognitive 81) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStatusWith (cyclomatic 29) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStopWith (cognitive 79) (src/Grace.CLI/Command/Agent.CLI.fs)
  • AgentCommand.workStopWith (cyclomatic 31) (src/Grace.CLI/Command/Agent.CLI.fs)
  • Annotation.validateLinkIntegrity (cognitive 23) (src/Grace.Types/Annotation.Types.fs)
  • Annotation.validateLinkIntegrity (cyclomatic 19) (src/Grace.Types/Annotation.Types.fs)
  • …and 799 more

New (34)

  • Ambiguous naming for related retrieval operations. 'GetBranch' likely retrieves the branch entity itself, while 'GetBranchReference' retrieves a specific reference associated with a branch. However, 'GetParentBranch' suggests retrieving the parent entity, whereas 'GetBranchReference' suggests retrieving a reference object. The distinction between 'Branch' (entity) and 'Reference' (pointer) is clear, but 'GetParentBranch' breaks the pattern of 'Get[Entity]By[Attribute]' or 'Get[Entity]Reference'. It is unclear if 'GetParentBranch' returns a BranchDto or a ReferenceDto.
  • CI runs a third-party container image from a mutable tag (.github/workflows/validate.yml)
  • CI runs a third-party container image from a mutable tag (.github/workflows/validate.yml)
  • CI runs a third-party container image from a mutable tag (.github/workflows/validate.yml)
  • Change coupling: Diff.Actor.fs ↔ Organization.Actor.fs (src/Grace.Actors/Diff.Actor.fs)
  • Change coupling: Organization.Actor.fs ↔ Reference.Actor.fs (src/Grace.Actors/Organization.Actor.fs)
  • Change-coupling hub: BranchName.Actor.fs → Organization.Actor.fs, Owner.Actor.fs, OwnerName.Actor.fs (src/Grace.Actors/BranchName.Actor.fs)
  • Change-coupling hub: OrganizationName.Actor.fs → Branch.Actor.fs, OwnerName.Actor.fs, Repository.Actor.fs (src/Grace.Actors/OrganizationName.Actor.fs)
  • Change-coupling hub: RepositoryName.Actor.fs → Branch.Actor.fs, BranchName.Actor.fs, OrganizationName.Actor.fs, Owner.Actor.fs, OwnerName.Actor.fs (src/Grace.Actors/RepositoryName.Actor.fs)
  • Documentation: contradicts the code (docs/Validation coverage final audit.md)
  • Documentation: no installation or build instructions (README.md)
  • Documentation: written for insiders (docs/The potential for misusing Grace.md)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • Inconsistent naming for 'Get/Read' operations. While most APIs use 'Get' (e.g., GetBranch, GetRepository, GetOrganization), the approvals and webhooks APIs use 'Show' for single-item retrieval. This creates a confusing split in verb usage for the same intent.
  • Inconsistent parameter naming for hash-based lookups. The methods 'GetDirectoryVersionByBlake3Hash' and 'GetDirectoryVersionBySha256Hash' explicitly include the hash algorithm in the method name. However, 'GetDirectoryVersion' likely takes an ID. While this is a common pattern, it is worth noting that 'GetDiffByBlake3Hash' and 'GetDiffBySha256Hash' in diffs_api follow the same pattern, ensuring consistency within the project, but the explicit inclusion of the hash type in the method name is a specific design choice that differs from generic 'GetById' patterns. This is not a strict inconsistency but a notable pattern deviation from standard RESTful 'Get/{id}' conventions, though it is internally consistent across directories and diffs.
  • Leaked secret: signing-key (src/Grace.Shared/Constants.Shared.fs)
  • Medium IaC: CKV_AZURE_101 (infra/modules/cosmos.bicep)
  • …and 14 more

Changes since last survey

  • 300 commits — 275 feature/other, 25 fixes

By area

  • (repo) — 88 commits
  • src/Grace.CLI — 56 commits
  • src/Grace.Server — 25 commits
  • docs/design — 17 commits
  • src/Grace.CLI.Tests — 16 commits
  • docs/Working Directory Update.md — 12 commits
  • sdk/generated — 11 commits
  • src/Grace.Server.Tests — 11 commits
  • src/Grace.Actors — 9 commits
  • (root) — 8 commits
  • docs/adr — 6 commits
  • docs/Design concepts — 4 commits
  • scripts/tests — 4 commits
  • scripts/modules — 3 commits
  • src/Grace.Cache — 3 commits
  • src/Grace.Shared — 3 commits
  • .github/PULL_REQUEST_TEMPLATE.md — 2 commits
  • docs/Grace Cache implementation audit.md — 2 commits
  • infra/README.md — 2 commits
  • infra/modules — 2 commits

Notable commits

  • fix: Fix Connect materialization boundary consistency
  • fix: Fix SDK metadata freshness proof
  • fix: Fix WDU prepared content validation edges
  • fix: Fix WDU target topology manifest ordering
  • fix: Fix WDU topology classification completeness
  • fix: Fix Watch reset recovery startup ordering
  • fix: Fix configuration write failure output
  • fix: Fix description clear OpenAPI propagation
  • fix: Fix description clear retry retention
  • fix: Fix description input introspection and test dispatch proof
  • fix: Fix duplicate-path status rebuilding
  • fix: Fix exact local state repair ownership
  • fix: Fix operational configuration snapshot races
  • fix: Fix operations SQL Entra provider packaging (#980)
  • fix: Fix working directory update contract validation
  • fix: fix(cli): close cache-required connect review findings
  • fix: fix(wdu): preserve retry evidence and Watch outcome
  • fix: fix(wdu): require exact projection packet identities
  • fix: fix(wdu): retain DirectoryVersion Branch selection
  • fix: fix: export WDU lifecycle raw bytes
  • …and 280 more

API surface

  • 3 added · 0 removed (a removed endpoint is potentially breaking)

Added endpoints (3)

  • GET /fill-public-key
  • GET /repositories/{repositoryId}/directory-version-zips/{directoryVersionId}
  • POST /repositories/{repositoryId}/directory-version-zips/{directoryVersionId}/fill

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

ScottArbeit/Grace was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 24 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit f746b688e0d20fdfdc46eedb42bd8d301be61a34 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-955b9cee9818.