# Source Registry Admin Dry-Run Add Validate Workflow V01

Issue: [#339](https://github.com/pinklon/ai-capability-discipline/issues/339)

Date: 2026-06-28

Repository: `pinklon/ai-capability-discipline`

Baseline commit: `e46dda7618ad0d916fadfde33f84cf5b84c2f27f`

Status: dry-run add_source plus validate_source workflow depth only. This ticket adds dry-run add_source plus validate_source workflow depth only. This ticket does not implement live Source Registry Admin commands, does not mutate source registries, does not mutate Preview or Production source sets, does not enable sources, does not disable sources, does not retire sources, does not promote sources, does not use Cloudflare CLI or API, does not call external URLs, does not change provider or model configuration, does not change runtime retrieval behavior, does not change package authority, does not start Production apply, does not start OKF implementation, does not start Google SDLC implementation, does not start multi-agent orchestration implementation, does not create Source Registry Admin live implementation child issues, does not create extraction-profile implementation tickets, does not close #271, does not reopen #269, does not close #269, and does not apply `codex-automerge`.

## Purpose

Prove the first end-to-end dry-run workflow for adding and validating a governed source record through Source Registry Admin.

The workflow demonstrates that a candidate source can move through `add_source` and `validate_source` dry-run posture with schema validation, lifecycle posture, refusal checks, receipt-preview output, snapshot posture, last-known-good posture, and boundary confirmations. It does not write registry state.

## Relationship To Product Requirements

#325 / PR #326 defines Source Registry Admin product requirements.

Those requirements establish Source Registry Admin as governed source lifecycle administration for enrichment lanes, including add/register source approval, lifecycle states, source record fields, citation behavior, extraction-profile dependency, and guardrails. This workflow slice proves a repo-local dry-run path for those requirements without authorizing live administration.

## Relationship To Command Contract

#329 / PR #330 defines Source Registry Admin command contract v01.

The command contract defines `add_source`, `validate_source`, command inputs, outputs, refusals, receipts, lifecycle transitions, environment behavior, authority-lane behavior, and validation boundaries. This workflow layer composes the existing commands into an add-then-validate dry-run sequence.

## Relationship To Schema/Lifecycle Validation

#331 / PR #332 defines Source Registry Admin schema and lifecycle validation.

The workflow reuses source-record schema and lifecycle checks for source ID, duplicate source ID, HTTPS canonical URL posture, bounded origin, bounded path prefix, authority lane, active enrichment retrieval profile, active enrichment extraction profile, approval posture, citation fields, lifecycle state, active environments, and audit-history preservation.

## Relationship To Dry-Run Parser

#333 / PR #334 defines Source Registry Admin dry-run command parser v01.

The parser remains dry-run only. This slice adds workflow-level evaluation over existing parser command results. The workflow evaluator accepts repo-local JSON fixtures, evaluates command sequence posture, emits per-step receipt previews, and returns a final workflow summary.

## Relationship To Receipt-Preview Schema

#335 / PR #336 defines Source Registry Admin dry-run receipt schema enforcement.

The workflow output keeps the same receipt-preview discipline. Accepted workflows include `receipt_previews` for each command step. Refused workflows include either command receipt previews already produced before refusal or a refusal receipt posture when the workflow fails before command execution.

## Relationship To Registry Snapshot / Last-Known-Good Model

#337 / PR #338 defines Source Registry Admin dry-run registry snapshot and last-known-good posture.

The workflow emits `snapshot_posture` and `last_known_good_posture`. For `add_source` and `validate_source`, registry snapshot posture is required as evidence context, while last-known-good is recorded as not required because the workflow does not mutate active source sets.

## Non-Goals

This dry-run add/validate workflow slice does not:

- implement live Source Registry Admin commands
- mutate source registries
- mutate Preview or Production source sets
- enable, disable, retire, or promote any source
- use Cloudflare CLI or API
- call external URLs
- change provider or model configuration
- change runtime retrieval behavior
- change package authority
- start Production apply
- start OKF implementation
- start Google SDLC implementation
- start multi-agent orchestration implementation
- create Source Registry Admin live implementation child issues
- create extraction-profile implementation tickets
- close #271
- reopen #269
- close #269
- apply `codex-automerge`

This ticket does not implement live Source Registry Admin commands.

This ticket does not mutate source registries.

This ticket does not mutate Preview or Production source sets.

## Workflow Model

The dry-run workflow evaluator supports:

- `add_source`
- `validate_source`
- `add_source_plus_validate_source`

`add_source` evaluates a proposed source record as a dry-run add request.

`validate_source` evaluates a proposed or registered source record as a dry-run validation request.

`add_source_plus_validate_source` evaluates an ordered `add_source` command followed by a `validate_source` command for the same `source_id`. The sequence emits command-level receipt previews and a final workflow summary. It does not write the proposed source to any registry between steps.

## Accepted Workflow Output

Accepted workflow output includes:

- `dry_run: true`
- `workflow`
- `workflow_status`
- `commands`
- `source_id`
- `initial_lifecycle_state`
- `proposed_lifecycle_state`
- `validation_checks`
- `refusal_checks`
- `receipt_previews`
- `snapshot_posture`
- `last_known_good_posture`
- `mutations_performed: false`
- `boundary_confirmations`

Accepted workflow status is `accepted`.

## Refused Workflow Output

Refused workflow output includes:

- `dry_run: true`
- `workflow`
- `workflow_status`
- `source_id` when available
- `reason`
- `failed_checks`
- `receipt_previews` or `refusal_receipt_posture`
- `mutations_performed: false`
- `boundary_confirmations`

Refused workflow status is `refused`.

## Valid Fixture Strategy

Valid fixtures live in `validation/fixtures/source_registry_admin/dry_run_add_validate_workflows_valid_v01.json`.

They cover:

- proposed current/public enrichment source with valid source metadata
- source record with valid HTTPS canonical URL
- source record with bounded allowed origin and path prefix
- source record with retrieval and extraction profile IDs
- source record with approval evidence posture
- source record with citation label and citation URL
- workflow that dry-runs `add_source` then `validate_source` and ends with no mutation

## Invalid Fixture Strategy

Invalid fixtures live in `validation/fixtures/source_registry_admin/dry_run_add_validate_workflows_invalid_v01.json`.

They cover refusal for:

- missing source ID
- duplicate source ID
- wildcard origin
- broad path prefix
- missing authority lane
- package-authority promotion attempt
- missing retrieval profile
- missing extraction profile
- missing approval evidence for validation-ready posture
- missing citation fields
- non-HTTPS canonical URL without explicit doc-only justification
- arbitrary web search request
- user-provided URL retrieval outside governed `add_source`
- browser-side source fetch
- command sequence attempting live mutation outside dry-run mode
- source deletion or audit-history erasure

## Receipt-Preview Behavior

Each accepted command step emits a dry-run receipt preview. The receipt previews carry `dry_run: true`, `mutations_performed: false`, command name, validation checks, refusal checks, lifecycle posture, snapshot posture, citation-use documentation impact, and `boundary_confirmations`.

Workflow-level refusal before command execution emits `refusal_receipt_posture` so the refusal still has receipt-preview posture without inventing command execution.

## Snapshot/LKG Posture

Workflow output includes `snapshot_posture`.

`snapshot_posture` records that registry snapshot evidence is required for the workflow evidence trail, that this is dry-run snapshot posture only, and that `mutations_performed: false`.

Workflow output includes `last_known_good_posture`.

`last_known_good_posture` records whether any step requires last-known-good evidence. For this slice, `add_source` and `validate_source` do not require last-known-good because they do not mutate Preview or Production source sets.

## Boundary Confirmations

No source registries were mutated.

No source sets were mutated.

No source was enabled, disabled, retired, or promoted.

No Cloudflare CLI or API was used.

No external URLs were called.

No provider or model configuration was changed.

No runtime retrieval behavior was changed.

No package authority was changed.

#271 remains open.

#269 remains closed.

`codex-automerge` was not applied.

## Post-Closeout Next Action

After this dry-run add_source plus validate_source workflow slice is merged and locally closed out, choose whether to add dry-run Preview enable/disable workflow depth or continue extraction-profile work for the next source.