docs: cleanup

Author: vim89

COMMERCIAL_LICENSE.md

@@ -70,6 +70,6 @@ IN WITNESS WHEREOF, the parties have executed this Agreement as of the Effective
 ---
 
 ### Schedules
-- **Schedule A (Scope)** — define use cases, modules, user count, and region.  
-- **Schedule B (Fees)** — fees, payment schedule, and currency.  
-- **Schedule C (Support / Updates)** — support obligations, SLA, maintenance plan.
+- **Schedule A (Scope)** - define use cases, modules, user count, and region.  
+- **Schedule B (Fees)** - fees, payment schedule, and currency.  
+- **Schedule C (Support / Updates)** - support obligations, SLA, maintenance plan.

CONTRIBUTING.md

@@ -38,7 +38,7 @@ This avoids rework and helps maintain consistent architecture.
 
 ## Build, test, and development commands
 
-- `sbt compile` — compile all modules; `sbt test` — run all tests (non‑parallel).
+- `sbt compile` - compile all modules; `sbt test` - run all tests (non‑parallel).
 - Formatting: `sbt fmt` / `sbt fmtCheck`; Linting: `sbt fix` / `sbt fixCheck`.
 - Focused runs: `sbt core/test`, `sbt engines-spark/compile`.
 - CLIs: `sbt validation-cli/run` and `sbt contracts-extractor-cli/run`.
@@ -246,7 +246,7 @@ trait LegacyCompatibility[F[_] : Sync] extends ConfigurationAlgebra[F] {
 - A class and its companion should live together in the same file. 
 - sealed traits and their subtypes must also be in the same file for compiler safety.
 - File names usually match the main type they hold.
-- Multi-type grouping: When types are closely related, grouping is permitted—but only when justified. The file should then use meaningful lowerCamelCase names. 
+- Multi-type grouping: When types are closely related, grouping is permitted-but only when justified. The file should then use meaningful lowerCamelCase names. 
 - Developer ergonomics: Having one type per file helps with navigation, findability, and code review. It avoids confusion and reduces search friction.
 
 ## Commit & Pull Request guidelines

README.md

@@ -41,7 +41,7 @@
 "A partner team removed a nullable column late Friday. We couldn’t roll back in time; both teams were up all night. If that change had been a compile error, we would have slept."
 
 ### For Python/ETL folks (dbt/Airflow/Informatica/Talend): 
-Think "contracts like Pydantic/Avro — but enforced before jobs run," "pure functions you can test without a cluster," and "connectors/engines that make IO explicit and safe."
+Think "contracts like Pydantic/Avro - but enforced before jobs run," "pure functions you can test without a cluster," and "connectors/engines that make IO explicit and safe."
 
 ### For EMs / Staff Data Architects: 
 You get compile‑time guarantees (not CI or runtime heuristics), a small opinionated surface, and batteries‑included defaults with escape hatches.
@@ -91,7 +91,7 @@ You get compile‑time guarantees (not CI or runtime heuristics), a small opinio
 ## Guarantees (Non‑negotiables)
 
 - Compile‑fail contracts for typed endpoints under policy lattice
-- Typestate builder: `build()` only when complete — incomplete pipelines can’t compile
+- Typestate builder: `build()` only when complete - incomplete pipelines can’t compile
 - Pure transforms; effectful edges; idempotent side‑effects by design
 - See: docs/design/framework-behaviors.md
 
@@ -118,7 +118,7 @@ Relax the policy to Backward (allows extra producer fields and missing optional/
 implicitly[SchemaConforms[Out, Contract, SchemaPolicy.Backward]] // ✅
 ```
 
-**3) Build a pipeline — typestate forbids incomplete builds**
+**3) Build a pipeline - typestate forbids incomplete builds**
 ```scala
 import cats.effect.IO
 import com.flowforge.core.PipelineBuilder
@@ -144,9 +144,9 @@ PipelineBuilder[IO]("demo")
 
 | Path | Goal | Commands |
 |------|------|----------|
-| A — Examples | Try locally (no cluster) | `sbt ffDev` (compile + focused tests), `sbt ffRunSpark` (Spark local[*]) |
-| B — Red→Green | See compile‑time error then fix | Use the snippet above; run `sbt compile` |
-| C — New project | Scaffold with g8 | `sbt new flowforge.g8 --name="ff-demo" --organization="com.acme"` then `sbt test` / `sbt run` |
+| A - Examples | Try locally (no cluster) | `sbt ffDev` (compile + focused tests), `sbt ffRunSpark` (Spark local[*]) |
+| B - Red→Green | See compile‑time error then fix | Use the snippet above; run `sbt compile` |
+| C - New project | Scaffold with g8 | `sbt new flowforge.g8 --name="ff-demo" --organization="com.acme"` then `sbt test` / `sbt run` |
 
 ## Compatibility
 

docs/adr/000-template.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 000 — <Title>
+# ADR 000 - <Title>
 
 - **Status**: Proposed / Accepted / Superseded by ADR-XXX
 - **Date**: <YYYY-MM-DD>
@@ -22,8 +22,8 @@
 - Operational: <perf, observability, testing>
 
 ## Alternatives Considered
-- Option A — <why rejected>
-- Option B — <why rejected>
+- Option A - <why rejected>
+- Option B - <why rejected>
 
 ## Verification
 - Build/test steps (sbt compile/scalafmtAll/test).

docs/adr/001-effect-system-abstraction.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 001 — Unified Effect System Abstraction (EffectSystem[F[_]])
+# ADR 001 - Unified Effect System Abstraction (EffectSystem[F[_]])
 
 - Status: Accepted
 - Date: 2025-09-04
@@ -32,7 +32,7 @@ We require a unified abstraction over effect systems to support IO boundaries, r
 
 ## Milestones
 - M1: IO/ZIO instances audited with law/property tests (present).
-- M2: Leaf modules depend on `EffectSystem[F]` only (no direct IO/ZIO)—see Evidence and Plan.
+- M2: Leaf modules depend on `EffectSystem[F]` only (no direct IO/ZIO)-see Evidence and Plan.
 - M3: Observability and resource-safety wired at IO boundaries (see ADR-007, ADR-013).
 
 ## Open Questions

docs/adr/002-spark-purity-and-io-boundaries.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 002 — Spark Purity and Effectful IO Boundaries
+# ADR 002 - Spark Purity and Effectful IO Boundaries
 
 - Status: Accepted
 - Date: 2025-09-04

docs/adr/003-contracts-first-and-typed-path.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 003 — Contracts-First and Typed Compile-Time Path
+# ADR 003 - Contracts-First and Typed Compile-Time Path
 
 - Status: Accepted
 - Date: 2025-09-04

docs/adr/004-modules-engines-and-templates-alignment.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 004 — Modules, Engines, and Templates Alignment
+# ADR 004 - Modules, Engines, and Templates Alignment
 
 - Status: Accepted
 - Date: 2025-09-04

docs/adr/005-quality-and-deequ-adapter.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 005 — Quality and Deequ Adapter MVP
+# ADR 005 - Quality and Deequ Adapter MVP
 
 - Status: Proposed
 - Date: 2025-09-04

docs/adr/006-connectors-strategy.md

@@ -1,5 +1,5 @@
 ```markdown
-# ADR 006 — Connectors Strategy (Local/HDFS now; Cloud later)
+# ADR 006 - Connectors Strategy (Local/HDFS now; Cloud later)
 
 - Status: Accepted
 - Date: 2025-09-04