# Job Runner Constitution
## Core Principles
### I. .NET 10 Platform Baseline
All production services, libraries, and tools MUST target .NET 10 unless a documented
exception is approved through Governance. Dependencies MUST be actively maintained and
compatible with the .NET 10 runtime profile used by this repository.
Rationale: A single runtime baseline reduces upgrade risk, avoids fragmented build
pipelines, and improves operational consistency.
### II. Clean Architecture Boundaries
The codebase MUST enforce Clean Architecture boundaries: domain logic MUST remain
framework-agnostic, application use cases MUST orchestrate behavior, and infrastructure
adapters MUST implement interfaces owned by inner layers. Dependencies MUST point inward,
and cross-layer shortcuts are prohibited without an approved exception.
Rationale: Explicit boundaries preserve maintainability, enable unit testing at the core,
and allow infrastructure changes without domain rewrites.
### III. Test Strategy and Coverage Discipline
Comprehensive automated tests are mandatory for every feature and fix. Test investment
MUST follow this priority order: unit tests first, integration tests second, and end-to-end
tests third. Pull requests MUST include evidence that new behavior is covered at the
lowest effective test level before higher-level tests are added.
Rationale: This test pyramid minimizes feedback time and cost while preserving confidence
in system behavior.
### IV. Structured Logging and Centralized Error Handling
All runtime components MUST emit structured logs with consistent fields, including
correlation identifiers, operation context, and severity. Error handling MUST be
centralized at service boundaries so exceptions are translated to stable, observable
responses and are never silently swallowed.
Rationale: Standardized telemetry and centralized error policies accelerate debugging,
improve reliability, and support production diagnostics.
### V. Azure Deployment Readiness
All deployable workloads MUST be designed for Azure-hosted environments. Infrastructure,
configuration, health checks, and release workflows MUST be automatable and environment-
aware (local, staging, production). Deployments MUST be reproducible and validated through
pipeline checks before promotion.
Rationale: Azure-first operational readiness reduces release friction and aligns
implementation decisions with hosting realities.
## Architecture and Platform Constraints
- All new APIs MUST define explicit contracts and versioning strategy before implementation.
- Dependency injection MUST be used at composition roots; service location is prohibited.
- Application configuration MUST be externalized and environment-specific secrets MUST NOT
be committed to source control.
- Observability defaults MUST include structured logs and error telemetry wiring from day 1.
- Any deviation from .NET 10, Clean Architecture boundaries, or Azure deployment assumptions
MUST be documented in the relevant spec and approved per Governance.
## Delivery Workflow and Quality Gates
- Feature specs MUST state how requirements map to unit, integration, and e2e tests.
- Plans MUST pass a constitution check before implementation starts and before merge.
- Tasks MUST include explicit work items for structured logging, centralized error handling,
and Azure deployment validation where applicable.
- Pull requests MUST include: architecture impact summary, test evidence, and deployment
readiness notes.
- CI pipelines MUST run mandatory quality gates (build, tests, and policy checks) before
protected branches are updated.
## Governance
This constitution is the authoritative engineering policy for this repository. In case of
conflict, this document takes precedence over informal conventions.
- Amendment Process: Changes require a documented proposal, reviewer approval, and explicit
update of impacted templates and guidance artifacts.
- Versioning Policy: Semantic versioning is mandatory for this constitution.
- MAJOR: incompatible governance or principle removals/redefinitions.
- MINOR: new principle or materially expanded guidance.
- PATCH: clarifications, wording improvements, and non-semantic refinements.
- Compliance Review: Every plan and pull request MUST include a constitution compliance
check. Non-compliant changes MUST not be merged without an approved exception.
- Runtime Guidance: Operational and implementation guidance in templates MUST stay aligned
with this constitution.
**Version**: 1.0.0 | **Ratified**: 2026-06-09 | **Last Amended**: 2026-06-09
I had already run /speckit.constitution, when I prompted Copilot with "Set up https://github.com/fstandhartinger/ralph-wiggum". It added a constitution above my existing constitution, in the same file.
Also, the generated constitution seems more geared toward a Ralph instructions file than a general constitution that establishing project standards. I'm also unclear how AI would interpret these instructions outside of a Ralph loop.
I definitely prefer the original version. Ralph instructions belong as another file in memory/ or somewhere else, IMO.
Original
Prepended text