# Checkpoint 1: Core Contracts And Skeleton

## Status

This document describes planned work, not implemented behavior.

## Goal

Define the stable vocabulary and core interfaces that adapters, extractors,
validators, and runners will build against.

This checkpoint should produce a compileable Go repository with a minimal CLI
shell and contract-level tests. It does not need to process real input or
produce useful artifacts.

## Scope

In scope:

- Go module bootstrap;
- executable entrypoint;
- minimal CLI package;
- core source, artifact, manifest, and contract types;
- fake implementation tests proving the interfaces are usable.

Out of scope:

- real input modules;
- real extract modules;
- LLM provider calls;
- prompt or response-schema assets;
- diagnostics run directory;
- production config loading.

## Target End State

The repository should contain a compileable Go application shell and stable core
contract packages:

- `cmd/notarius` provides the executable entrypoint.
- `internal/cli` provides a minimal CLI shell.
- `internal/core/source` defines generic source documents, source units, source
  references, and source validation helpers.
- `internal/core/artifacts` defines extractor-neutral artifact candidate,
  approved artifact, rejected artifact, and run manifest types.
- `internal/framework/contracts` defines the adapter, extractor, validator, and
  structured LLM interfaces used by later checkpoints.

The contracts should be proven with fake implementations in tests. Those tests
should demonstrate composition without real input modules, real extract modules,
LLM provider calls, prompt assets, or diagnostics infrastructure.

Implementation staging belongs in
[`implementation.md`](implementation.md).

## Done Criteria

- `go test ./...` passes.
- `go build ./cmd/notarius` passes.
- Core types and contracts exist in stable package locations.
- Tests prove fake implementations can compose at the type-contract level.
- No real Seriatim, D&D, LLM, or Audita-specific behavior has been added yet.

## Review Questions

- Are the interfaces small enough?
- Are source-format details absent from core packages?
- Are D&D concepts absent from framework and core packages?
- Is the shell compileable without placeholder behavior that will be hard to
  unwind?