dpcs 0.3.0

Reference implementation of the Data Pipeline Contract Standard (DPCS)
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

# Contributing

Thanks for helping build the DPCS reference implementation.

## Ground rules

1. Treat [`SPEC.md`](SPEC.md) as the authoritative source of truth.
2. If a design doc conflicts with `SPEC.md`, follow `SPEC.md`.
3. Prefer the smallest conservative behavior when the specification is ambiguous.
4. Add a `TODO` referencing the relevant SPEC section when deferring behavior.
5. Do not implement orchestrator binding or execution runtimes until roadmap 0.8.0.

## Releases

Tagged releases use `.github/workflows/release.yml`:

1. Push a version tag matching `v*.*.*` (for example `v0.3.0`).
2. The release workflow runs the same CI checks as pull requests (`ci-checks.yml`).
3. After checks pass, it publishes the Rust crate to crates.io.

Store a crates.io API token in the repository secret named `CARGO_REGISTRY_TOKEN`.
Do not use a PyPI token here; this project does not publish a Python package yet.


```bash
rustup toolchain install stable
cargo test --all-features
```

MSRV is **1.85**.

## Workflow

1. Create a focused branch.
2. Implement the change with tests.
3. Run:

   ```bash
   cargo fmt --all
   cargo clippy --all-targets --all-features -- -D warnings
   cargo test --all-features
   ```

4. Update docs when public behavior changes.
5. Open a pull request against `main`.

## Project map

| Path | Purpose |
| --- | --- |
| `SPEC.md` | Normative specification |
| `ROADMAP.md` | Release plan |
| `src/model` | Canonical Object Model |
| `src/parser` | YAML/JSON parsing |
| `src/validation` | Phase-based validation |
| `src/diagnostics` | Diagnostic types and reports |
| `tests/fixtures` | Conformance-oriented fixtures |
| `docs/` | Design guides |
| `adr/` | Architecture decisions |

## Validation diagnostics

New validation rules should:

- use stable ids (`DPCS-<AREA>-<NNN>`)
- set severity, stage, and category
- include an `object_ref` when possible
- include remediation guidance when actionable
- remain deterministic across runs

## Commit style

Use concise, present-tense commit messages that explain why the change exists:

```text
Add graph cycle detection to validation phase
```

## Code of conduct expectations

Be respectful, assume good intent, and keep review feedback specific and actionable.